Agent-built web app quality gate. Real browser is the judge. PASS/FAIL with receipts.
Copy the AI prompt to install this server into Claude Code, Cursor, or another agent β or use 1-click editor setup below.
π‘ Paste the JSON block into your client's configuration file under mcpServers, then restart the application.
δΈζ | English
Witness β The browser is the judge. The quality gate for agent-built web apps. Agents say done; the browser proves it. (Witness is the product name;
dsh-verifyis the package name β same thing.)
If Witness catches something for you, β star the repo β it's how this project stays alive.
You asked an AI to build a web app. It said "done." Does it actually work?
dsh-verify opens a real browser and checks β so you never have to take the agent's word for it.


The quality gate for agent-built web apps. Works with any agent β DeepSeek Harness (dsh), Claude Code, Cursor, Copilot, Codex β and with any CI. You write what a human would check in a browser; a real browser executes it and returns a PASS/FAIL verdict with receipts (screenshots + diff images).
No LLM judges the outcome. The browser is the judge.

Same task. Same AI. Two builds. One missing CSS rule β the agent's self-review passed, a real browser caught it.
We ran a 4-agent web team (spec writer β frontend dev β QA β reviewer). Their own review said:
β "All requirements met. No issues found."
In a real browser, the dark-mode toggle did nothing β the .dark class was toggled, but the CSS rule was never written. Every agent self-test passed because there was nothing in the page for the agents to run. No one opened a real browser.
That's the gap: agents verify against what they believe they built, not against what a user actually experiences. Unit tests and static checks can't catch a missing CSS rule.
| Build | What the agents said | What a real browser says |
|---|---|---|
demo/buggy | "No issues found" | β FAIL β background never changes |
demo/fixed | one CSS rule added | β PASS β theme flips |
Same page. Same JS. One missing CSS rule. Two different verdicts.
| What you might reach for | Its blind spot | What dsh-verify adds |
|---|---|---|
| Hand-rolled Playwright scripts | Every agent project re-writes the same boilerplate; nothing is reviewable as a spec | A JSON spec is the whole contract β write once, reuse across agents and CI |
| LLM judges (promptfoo-style evals) | An LLM says "looks right" β it doesn't run the app or see the pixels | A real browser executes clicks, inputs, styles, and returns screenshot receipts |
| Agent built-in browser tools | They're the agent's hands β they share the same blind spots as the code they just wrote | dsh-verify is an independent witness, not part of the agent being tested |
| Screenshot-only visual tools | They catch pixel drift, not "button does nothing" | Behavior checks: click, expect text/class/style change, console errors, network errors |
The agent graded its own homework. dsh-verify re-grades it in a real browser.
| Entry point | What it's for | One-liner |
|---|---|---|
| MCP server | Your AI agent verifies its own deliverable, mid-session | claude mcp add dsh-verify -- npx -y -p dsh-verify dsh-verify-mcp |
| CLI | You or your CI verify a build/URL | npx dsh-verify --spec demo/fixed.json |
| GitHub Action | Every push runs real-browser checks | uses: 263311487-ux/dsh-verify/.github/actions/dsh-verify@main |
Then tell your agent, in plain words:
Verify http://localhost:3000 β click
#dark-toggle, then checkbodybackground-color changed. Screenshot it.
Tools exposed: verify_spec (run a spec JSON), verify_url (inline checks, no files), generate_and_verify (the AI drafts the checklist, real Chromium executes it), health.
The repo dogfoods it: the dogfood workflow asserts the fixed build passes and the buggy build fails on every push.
--json for machines; exit 0/1 for CI.expect_screenshot), refresh with --update-baselines.dsh-verify gen --url ... --prompt "..." learns the page in a real browser, has an LLM draft the checklist, then executes it deterministically. The AI drafts; it never judges.chromium | firefox | webkit per spec or --browser.Top-level fields: title, serve (static dir) or base (target URL), browser, steps. Run many at once with a glob; exit is 0 only if all pass.
A self-contained HTML report β every step with a pass/fail badge, selector, and detail, plus screenshots:

Real-browser benchmark for agent-built web apps: same 3 tasks, same human checks, open entry. Run your model on the board in ~10 minutes:
Your setup appears on the live leaderboard next to DeepSeek v4-flash / v4-pro: agent-arena. Full rules in docs/ARENA.md.
The repo's own CI runs exactly that β engine self-tests, then asserts fixed passes and buggy fails β so the tool verifies itself on every push.
Same task, same prompt, same human checks β different agents, graded by dsh-verify in a real browser. Latest run (2026-08-19): 44/48 runs passed across 2 models Γ 2 strategies Γ 3 tasks, 4 runs per cell. Two counterintuitive findings: the pricier v4-pro single-shot scored below the cheaper v4-flash single-shot (10/12 vs 11/12), and a real-browser self-check loop lifted v4-pro to 12/12 β while v4-flash's self-check crashed once when its own verification report came back as corrupt JSON. Every failure is reproducible and invisible to an LLM judge.
See docs/ARENA.md β methodology, the tasks, and how to run your own agent.
Built something with an AI agent? Prove it in a real browser and show the world:
Add a spec, wire the GitHub Action, and the badge is earned, not claimed. See docs/verified-badge.md.
No reviews yet β be the first to share how this listing worked for you.
Showcase your server listing on GitHub or your project documentation. Embed this dynamic SVG badge to highlight official listing status and live engagement.
[](https://allmcps.com/mcp/dsh-verify)<a href="https://allmcps.com/mcp/dsh-verify"><img src="https://allmcps.com/api/badge/dsh-verify?style=directory" alt="Dsh Verify on AllMCPs" /></a>