dsh-verify
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| verify_specA | Run a dsh-verify acceptance spec (JSON file, or glob) against a real headless Chromium. The spec may serve a local static dir (spec.serve) or target any URL (spec.base / step.url). Returns PASS/FAIL with per-step results and a self-contained HTML report path. Exit-code semantics: ok=true means every step passed. This is deterministic — no LLM judges the outcome. |
| verify_urlA | Verify a live URL against a list of human-style checks, driven by a real headless Chromium. Checks are dsh-verify steps: goto/click/fill/wait/expect_text/expect_class/capture_style/expect_style_changed/expect_url_contains/expect_navigation/expect_console_errors/expect_network_errors/screenshot. If no goto step is given, a goto to the url is prepended. Returns PASS/FAIL with per-step results and a self-contained HTML report path. Deterministic — no LLM judges the outcome. |
| generate_and_verifyA | AI-drafts an acceptance checklist for a URL (LLM writes it, a real browser executes it), then immediately runs it in real Chromium. Pass requirements as a plain-language description of what a human QA should verify (e.g. "dark-mode toggle changes the background color"). Requires DEEPSEEK_API_KEY or OPENAI_API_KEY in the server environment. Returns the drafted spec path plus the PASS/FAIL verdict, per-step results and report path. |
| healthA | Check that the dsh-verify MCP server and its Chromium browser are ready to run verifications. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 4 tools
The tools are mostly distinct: health checks readiness, verify_spec runs a spec file/glob, verify_url runs ad-hoc checks on a URL, and generate_and_verify combines AI drafting with execution. There is slight overlap between verify_spec and verify_url, but input types clearly differentiate them.
Naming is mostly snake_case but inconsistent in style: health is a noun, verify_spec and verify_url follow verb_noun, while generate_and_verify is a compound verb phrase. The pattern is still readable but not uniform.
With 4 tools, the server is well-scoped. Each tool serves a distinct purpose in the verification workflow: readiness check, spec execution, live URL verification, and AI-assisted generation, with no redundancy.
The domain of running headless Chromium verifications is well covered: health, spec-based execution, ad-hoc checks, and AI-drafted specs. Minor gaps include no standalone spec generation without execution and no spec management, but these are not critical for the core workflow.