Which integrations are available for this server?

Integrates with Cypress testing framework, enabling AI-powered test automation, debugging, and script generation. Provides tools to run tests, generate tests from descriptions, validate test files, retrieve results, screenshots, and videos.

How do I use cypress-mcp-server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@cypress-mcp-server Run all Cypress tests in headless mode" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

cypress-mcp-server

by glh230

Overview Schema Related Servers Score Discussions

JavaScript

Local

Cypress MCP Server

A Model Context Protocol (MCP) server implementation that integrates Cypress with Cursor AI, enabling AI-powered test automation, debugging, and script generation.

🚀 Features

Full Cypress Integration: Supports all major Cypress commands and features
MCP Standard Compliant: Follows the official Model Context Protocol specification
Cursor AI Compatible: Seamlessly integrates with Cursor's AI assistant
Comprehensive Tool Set:
- Run tests in headless or headed mode
- Validate test files and code
- Generate tests from descriptions
- Retrieve test results, screenshots, and videos
- Execute Cypress commands programmatically
Security: Configurable command allowlist and execution time limits
Logging: Comprehensive logging with Winston
Flexible Configuration: YAML-based configuration with environment variable support

Related MCP server: AI Customer Support Bot - MCP Server

📋 Prerequisites

Node.js 18.0.0 or higher
npm or yarn package manager
Cypress project (existing or new)

🔧 Installation

Option 1: Install from npm (when published)

npm install -g cypress-mcp-server

Option 2: Install from source

git clone https://github.com/yourusername/cypress-mcp-server.git
cd cypress-mcp-server
npm install
npm link  # Optional: link globally for CLI access

⚙️ Configuration

1. Create Configuration File

Copy the example configuration file:

cp cypress-mcp.config.yaml.example cypress-mcp.config.yaml

2. Configure Cursor

Add the MCP server to Cursor's configuration. Open Cursor settings and add:

On macOS/Linux: ~/.cursor/mcp.json

On Windows: %APPDATA%\Cursor\mcp.json

{
  "mcpServers": {
    "cypress": {
      "command": "node",
      "args": ["/path/to/cypress-mcp-server/src/index.js"],
      "env": {
        "CYPRESS_MCP_CONFIG": "/path/to/cypress-mcp.config.yaml"
      }
    }
  }
}

Or if installed globally:

{
  "mcpServers": {
    "cypress": {
      "command": "cypress-mcp-server"
    }
  }
}

3. Customize Configuration

Edit cypress-mcp.config.yaml:

cypress:
  projectPath: /path/to/your/cypress/project
  browser: chrome
  headless: true
  baseUrl: http://localhost:3000
  viewportWidth: 1280
  viewportHeight: 720
  defaultCommandTimeout: 4000
  requestTimeout: 5000
  responseTimeout: 30000

mcp:
  name: cypress-mcp-server
  version: 1.0.0

security:
  allowedCommands:
    - '*'
  maxExecutionTime: 300000

🎯 Usage

Once configured, you can use natural language prompts in Cursor to interact with Cypress:

Running Tests

Run all Cypress tests in headless mode

Run the test file cypress/e2e/login.cy.js using Firefox

Run Cypress tests with baseUrl set to http://localhost:8080

Generating Tests

Generate a Cypress test that validates user login. The test should visit the login page, enter credentials, click login, and verify redirect to dashboard. Save it to cypress/e2e/login.cy.js

Validating Tests

Validate the Cypress test file cypress/e2e/checkout.cy.js for syntax errors

Getting Results

Show me the results from the last Cypress test run

Get all screenshots from failed tests

📚 Available Tools

The MCP server exposes the following tools:

`cypress_run`

Run Cypress tests with specified options.

Parameters:

spec (string, optional): Specific test file or glob pattern
browser (string, optional): Browser to use (chrome, firefox, edge, electron)
headless (boolean, optional): Run in headless mode
baseUrl (string, optional): Base URL for the application
env (object, optional): Environment variables
config (object, optional): Additional Cypress configuration

`cypress_open`

Open Cypress Test Runner in headed mode for interactive debugging.

Parameters:

browser (string, optional): Browser to open
project (string, optional): Path to Cypress project

`cypress_validate`

Validate a Cypress test file or test code.

Parameters:

testFile (string, optional): Path to test file
testCode (string, optional): Test code to validate

`cypress_generate`

Generate a Cypress test file from a description.

Parameters:

description (string, required): Description of the test
testName (string, optional): Name for the test
outputPath (string, optional): Path to save the generated test

`cypress_get_results`

Get test results from previous runs.

Parameters:

runId (string, optional): Specific run ID, or omit for all results

`cypress_get_screenshots`

Get screenshots captured during test runs.

Parameters:

runId (string, optional): Filter by run ID
testPath (string, optional): Filter by test path

`cypress_get_videos`

Get videos recorded during test runs.

Parameters:

runId (string, optional): Filter by run ID

`cypress_execute_command`

Execute a Cypress command directly (placeholder for advanced use cases).

📖 Examples

See the examples/ directory for:

Example Cypress test files
Sample Cursor prompts
Configuration examples

🧪 Testing

Run the test suite:

npm test

Run tests with coverage:

npm run test:coverage

🔒 Security

The MCP server includes several security features:

Command Allowlist: Configure which Cypress commands are allowed
Execution Time Limits: Prevent long-running tests from blocking
Input Validation: All inputs are validated before execution
Error Handling: Comprehensive error handling prevents crashes

📝 Logging

Logs are written to:

Console (development mode)
logs/error.log (errors only)
logs/combined.log (all logs)

Set the log level with the LOG_LEVEL environment variable:

LOG_LEVEL=debug node src/index.js

🐛 Troubleshooting

Server won't start

Check Node.js version: node --version (should be 18+)
Verify dependencies: npm install
Check configuration file syntax
Review logs in logs/ directory

Tests not running

Verify Cypress is installed: npx cypress verify
Check project path in configuration
Ensure baseUrl is accessible
Check browser permissions

Cursor not connecting

Verify MCP configuration in Cursor settings
Check file paths are absolute
Restart Cursor after configuration changes
Check console for connection errors

Browser issues

Ensure Chrome/Firefox is installed
Check browser permissions
Try running Cypress manually: npx cypress open
Review Cypress documentation for browser setup

🤝 Contributing

Contributions are welcome! Please:

Fork the repository
Create a feature branch
Make your changes
Add tests
Submit a pull request

📄 License

MIT License - see LICENSE file for details

🔗 Links

🙏 Acknowledgments

Anthropic for the Model Context Protocol specification
The Cypress team for an amazing testing framework
Cursor for AI-powered development tools

📧 Support

For issues, questions, or contributions:

Open an issue on GitHub
Check existing documentation
Review example files

Note: This is a community project and is not officially affiliated with Cypress, Cursor, or Anthropic.

Available Tools

8 tools

cypress_execute_commandC

Execute a Cypress command with chaining support. This is a lower-level tool for executing specific Cypress commands.

ParametersJSON Schema

Name	Required	Description
`command`	Yes	Cypress command to execute (e.g., "visit", "get", "click", "type")
`args`	No	Arguments for the command
`selector`	No	CSS selector or text to find element
`options`	No	Additional options for the command

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It only mentions 'chaining support' and 'lower-level', but fails to disclose side effects, permissions, error behavior, or any behavioral traits beyond basic execution.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise at two sentences, front-loading the main action. Every sentence serves a purpose, though additional context would be welcome. No structural issues.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (4 parameters, chaining support, no output schema), the description is too brief. It does not explain how chaining works, how to use the parameters effectively, or what the command execution returns, making it incomplete for safe and effective use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage for all 4 parameters, so the baseline is 3. The description adds no additional meaning beyond what the schema provides, e.g., it does not explain how 'args', 'selector', or 'options' interact with chaining.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states it executes a Cypress command with chaining support, which is a specific verb+resource. However, it does not distinguish from sibling tools like cypress_run, which might also execute commands but at a higher level.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description merely calls it a 'lower-level tool' but gives no explicit guidance on when to use it versus alternatives such as cypress_run or cypress_generate. No when-not or alternative tools are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

cypress_generateC

Generate a Cypress test file from a description

ParametersJSON Schema

Name	Required	Description
`description`	Yes	Description of what the test should do
`testName`	No	Name for the test
`outputPath`	No	Path where the generated test file should be saved

TDQS

C2.4/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, and the description is too brief (7 words) to disclose behavioral traits like side effects (e.g., file overwrite), authorization needs, or return behavior. For a generation tool, critical details are missing.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely concise (one sentence) but fails to provide necessary context. Efficiency is not valuable if the content is insufficient for correct use.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations, no output schema, and sibling tools, the description is woefully incomplete. Does not explain return values, error handling, or integration with other Cypress tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with descriptions for all parameters. However, the description adds no additional meaning beyond the schema; it merely repeats the action. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool generates a Cypress test file from a description. It distinguishes from sibling tools that execute, get results, etc., but could be more specific about the input format (e.g., natural language to code).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool vs alternatives. Missing context such as whether a project must be open, required dependencies, or exclusions (e.g., not for existing files).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

cypress_get_resultsA

Get test results from a previous Cypress run by run ID, or all results if no ID provided

ParametersJSON Schema

Name	Required	Description	Default
`runId`	No	Run ID to get results for (optional)

TDQS

A3.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description must fully disclose behavior. It only says 'get test results' without detailing what 'results' entail (e.g., pass/fail status, logs) or any side effects. The return format is not described, which is a significant gap for a tool with no output schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is one sentence, front-loaded, and contains no redundant information. Every word contributes to understanding the tool's core function.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (1 optional param, no output schema), the description gives a basic understanding. However, it lacks details on what constitutes 'results,' error handling, and return format. A more complete description would include brief output clarification.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds meaning beyond the schema by clarifying behavior when runId is omitted ('or all results if no ID provided'). The schema already covers the single parameter, so the description provides useful context.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb (get), resource (test results from a previous Cypress run), and scope (by run ID or all if no ID). It distinguishes from sibling tools like cypress_get_screenshots which target different resources.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It implies usage context: retrieving results from a previous run, optionally filtering by run ID. However, it does not explicitly mention when not to use this tool or suggest alternatives like cypress_get_screenshots for other data.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

cypress_get_screenshotsC

Get screenshots captured during test runs

ParametersJSON Schema

Name	Required	Description	Default
`runId`	No	Run ID to filter screenshots (optional)
`testPath`	No	Test path to filter screenshots (optional)

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Minimal behavioral disclosure. Does not mention whether filters are exclusive or additive, what happens with no filters, or any side effects. Since no annotations exist, the description should provide more context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, front-loaded with key action. Very concise, but could include more detail without becoming verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Lacks important context such as behavior when no filters are provided, return format, error handling, or any prerequisites. Incomplete for an AI agent to select and invoke confidently.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so both parameters are already documented. The description adds no additional meaning beyond the schema, meeting baseline expectations.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves screenshots from test runs. However, it does not differentiate from sibling tools like cypress_get_videos, which follow the same pattern.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance provided on when to use this tool over alternatives. No context on prerequisites or recommended scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

cypress_get_videosC

Get videos recorded during test runs

ParametersJSON Schema

Name	Required	Description	Default
`runId`	No	Run ID to filter videos (optional)

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description fully carries the transparency burden. It only states 'Get videos' without mentioning read-only nature, output format, or limits. Insufficient disclosure for a resource-fetching tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single-sentence description is concise and to the point. No structural issues, though additional detail could be added without breaking conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one optional parameter, the description is adequate but incomplete. It omits output details (no output schema), leaving the agent unsure about the return format.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with the parameter 'runId' fully described. The description adds no additional meaning, so baseline score of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action 'Get videos' and the resource 'recorded during test runs'. It is specific but does not differentiate from sibling tools like cypress_get_screenshots or cypress_get_results.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance provided on when to use this tool versus alternatives. With siblings like cypress_get_screenshots, explicit context is missing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

cypress_openB

Open Cypress Test Runner in headed mode for interactive debugging

ParametersJSON Schema

Name	Required	Description	Default
`browser`	No	Browser to open
`project`	No	Path to Cypress project

TDQS

B3.4/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses that the tool opens the Test Runner in headed mode, but does not explain side effects (e.g., whether it blocks, starts a server), authentication needs, or required project state. With no annotations, this leaves significant behavioral gaps for safe agent invocation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no waste. Every word serves to communicate the core purpose and mode concisely.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has no output schema and no annotations, yet the description does not mention return behavior (e.g., process handle, success indication) or whether it blocks execution. This is insufficient for an agent to understand the interaction lifecycle.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, and the description adds no additional meaning beyond the inline schema descriptions ('Browser to open', 'Path to Cypress project'). Baseline 3 is appropriate as the schema already documents both parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Open'), resource ('Cypress Test Runner'), and mode ('headed mode for interactive debugging'). It effectively differentiates from sibling tools like cypress_run (runs tests) and cypress_execute_command (executes commands).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for interactive debugging by stating 'headed mode', but lacks explicit guidance on when to use this tool versus alternatives such as cypress_run or cypress_execute_command. No prerequisites or exclusions are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

cypress_runB

Run Cypress tests with specified options. Returns test results including pass/fail counts, duration, and run ID.

ParametersJSON Schema

Name	Required	Description
`spec`	No	Specific test file or glob pattern to run (e.g., "cypress/e2e/login.cy.js")
`browser`	No	Browser to run tests in
`headless`	No	Run in headless mode (default: true)
`baseUrl`	No	Base URL for the application under test
`env`	No	Environment variables to pass to Cypress
`config`	No	Additional Cypress configuration options

TDQS

B3.2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description must disclose behaviors but only mentions it runs tests and returns results. Missing side effects like generating artifacts, duration, or environmental requirements.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One sentence, 14 words, entirely front-loaded with the action. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite 6 parameters and no output schema, the description is minimal. It mentions return fields but lacks detail on structure or behavior. Incomplete for a complex tool like Cypress test runner.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with parameter descriptions. The description adds no extra meaning beyond 'with specified options'. Baseline 3 applies as schema already documents parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Run', the resource 'Cypress tests', and the outcome 'returns test results including pass/fail counts, duration, and run ID'. It distinguishes from sibling tools like cypress_execute_command which likely executes individual commands.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool vs alternatives, no prerequisites or context provided. Given multiple sibling tools, explicit usage guidelines would help an agent decide.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

cypress_validateB

Validate a Cypress test file or test code for syntax and best practices

ParametersJSON Schema

Name	Required	Description	Default
`testFile`	Yes	Path to test file to validate
`testCode`	No	Test code to validate (alternative to testFile)

TDQS

B3.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations are absent, so the description must provide behavioral context. It only states validation of syntax and best practices, without detailing failure behavior, read-only nature, or side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence with no unnecessary words. Front-loaded and efficient, though may be too minimal for full clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema and no annotations. The description omits what validation returns (errors, success status), leaving the agent without crucial information for a validation tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds little beyond schema; it mentions testCode as alternative to testFile, but this is already implied by schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool validates Cypress test files or code for syntax and best practices. The verb 'validate' and resource are specific, and it distinguishes from sibling tools like cypress_run or cypress_generate.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool vs alternatives. Sibling tools are different, but the description does not mention scenarios or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

8 tool updatesv1.0.0May 29, 2026
- First observedcypress_execute_command
- First observedcypress_generate
- First observedcypress_get_results
- First observedcypress_get_screenshots
- First observedcypress_get_videos
- First observedcypress_open
- First observedcypress_run
- First observedcypress_validate

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.4/5.0

Disambiguation5/5

Each tool has a distinct purpose: running, generating, validating, retrieving results/screenshots/videos, and opening the runner. No two tools overlap in function; the boundaries are clear.

Naming Consistency5/5

All tools follow a consistent 'cypress_verb_noun' pattern in snake_case, making them predictable and easy to differentiate.

Tool Count5/5

With 8 tools, the set covers core Cypress workflows (generate, run, validate, retrieve artifacts) without being overly large or sparse.

Completeness4/5

The set covers the major stages of Cypress testing: generation, validation, execution, and artifact retrieval. Missing a tool to explicitly list or delete tests, but the core lifecycle is well-supported.

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

hithereiamaliff-mcp-nextcloudOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Cloud Storage File Systems Workplace & Productivity
237
mcp COAuth
com.wix
A Model Context Protocol server for Wix AI tools
Developer Tools Content Management Systems App Automation
216
anotherai
dev.anotherai
MCP server for building and testing AI agents with multi-model experimentation and insights.
Agent Orchestration Autonomous Agents Testing & QA Tools
2
mintqa-mcp
io.github.adamgusky
MCP server for Mint — AI-powered QA that runs your app in a real browser on every PR.
Testing & QA Tools CI/CD & DevOps
2

Related MCP Servers

Cursor MCP Installer
Developer Tools App Automation Version Control
matthewdcage
A
license
A
quality
C
maintenance
A Model Context Protocol (MCP) server for Cursor IDE that simplifies the installation and configuration of other MCP servers.
Updated 5 months ago (2026-04-11 14:16 UTC)
3
17
77
MIT
AI Customer Support Bot - MCP
Customer Support RAG Systems Agent Orchestration
ChiragPatankar
A
license
Not graded
quality
D
maintenance
A Model Context Protocol (MCP) server that provides AI-powered customer support using Cursor AI and Glama.ai integration.
Updated a year ago (2025-08-24 12:26 UTC)
4
MIT
Testomatio MCP Serverofficial
Testing & QA Tools Project Management API Testing
testomatio
A
license
Not graded
quality
A
maintenance
A Model Context Protocol server that enables AI assistants like Cursor to interact with Testomatio test management platform, allowing users to query test cases, runs, and plans through natural language.
Updated 3 days ago (2026-09-03 11:41 UTC)
519
7
MIT
Shortcut MCP Server
Project Management Developer Tools
ampcome-mcps
A
license
B
quality
D
maintenance
A Model Context Protocol server that integrates Shortcut project management functionality with AI assistants like Cursor, Windsurf, Claude Code, and Zed.
Updated a year ago (2025-08-04 05:55 UTC)
33
19,686
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/glh230/cypress-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

Cypress MCP Server

🚀 Features

📋 Prerequisites

🔧 Installation

Option 1: Install from npm (when published)

Option 2: Install from source

⚙️ Configuration

1. Create Configuration File

2. Configure Cursor

3. Customize Configuration

🎯 Usage

Running Tests

Generating Tests

Validating Tests

Getting Results

📚 Available Tools

cypress_run

cypress_open

cypress_validate

cypress_generate

cypress_get_results

cypress_get_screenshots

cypress_get_videos

cypress_execute_command

📖 Examples

🧪 Testing

🔒 Security

📝 Logging

🐛 Troubleshooting

Server won't start

Tests not running

Cursor not connecting

Browser issues

🤝 Contributing

📄 License

🔗 Links

🙏 Acknowledgments

📧 Support

Available Tools

Tool Schema Changelog

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Testomatio MCP Serverofficial

Latest Blog Posts

MCP directory API

`cypress_run`

`cypress_open`

`cypress_validate`

`cypress_generate`

`cypress_get_results`

`cypress_get_screenshots`

`cypress_get_videos`

`cypress_execute_command`