cypress-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| CWD | Yes | The path to the Cypress project directory |
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 | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| cypress_discoverA | Discover and map the entire Cypress test suite. Returns all specs with test counts, describe blocks, and test names. Use this first to understand what tests exist before writing or running anything. |
| cypress_analyze_specA | Deep analysis of a single spec file. Extracts describe/it blocks with line numbers, cy.visit URLs, cy.intercept routes, fixtures used, and custom commands called. |
| cypress_list_specsB | List all Cypress spec files in the project. Returns file paths and test counts. |
| cypress_run_specA | Run a single Cypress spec file headless. Returns structured results with pass/fail counts, failure details, screenshot paths, and recommended next actions. |
| cypress_run_testA | Run a specific test by name within a spec file using grep. Returns structured results with recommended next actions for the agent. |
| cypress_rerun_lastA | Replay the exact last run_spec or run_test invocation. Removes friction when iterating on the same failure — no need to reconstruct arguments. |
| cypress_get_last_runA | Return the full structured results of the most recent Cypress test run including runId, args used, and all test details. |
| cypress_get_failure_contextA | Get a compact debugging bundle for the most recent failure. Returns the failing test, error, stack hint, screenshot paths, relevant spec excerpt, and recommended next actions. This is the key tool for the fix-and-rerun loop. |
| cypress_get_screenshotA | Find screenshot files from Cypress test failures. Returns absolute file paths that multimodal AI agents can read directly. |
| cypress_get_envA | Return the contents of cypress.env.json with sensitive values masked. Safe to display. |
| cypress_doctorA | Comprehensive health check of the Cypress project. Validates config file, binary, spec files, support file, and directories. Use this to diagnose setup issues. |
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 11 tools
Most tools have clearly distinct purposes, but cypress_discover and cypress_list_specs both list specs, with discover providing more detailed information. Descriptions make the difference clear, so confusion is unlikely, though there is slight overlap.
All tools share the cypress_ prefix and use snake_case, with most following a verb_noun pattern (e.g., analyze_spec, run_spec, get_last_run). A few like 'discover' and 'doctor' are single words, deviating slightly from the pattern, but the overall style is predictable and consistent.
With 11 tools, the set is well-scoped for a Cypress testing server. It covers discovery, execution, analysis, debugging, environment inspection, and health checks without unnecessary bloat.
The tools provide comprehensive coverage of the Cypress testing lifecycle: discover specs, analyze them, run tests, retrieve results, debug failures with screenshots and context, and run environment checks. The only minor gap is a lack of a bulk run-all tool, but that can be worked around by running specs individually.