Enables serverless deployment on AWS Lambda for scalable test execution and analysis
Provides tools for generating and executing Cypress tests, supporting unit, component, and e2e test types for JavaScript/TypeScript code
Provides containerization support for deploying the testing server in isolated environments
Supports deployment to Google Cloud Run for serverless operation of the testing infrastructure
Analyzes JavaScript code to determine appropriate testing strategies and generate tests based on the code structure
Enables generating and running Jest tests for JavaScript/TypeScript code, with specific support for unit and component testing
Offers specialized tools for testing React components, including automated test generation and execution with props handling
Analyzes TypeScript code to determine testing approaches and generate appropriate tests with type-aware capabilities
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MCP Frontend Testing Server generate a unit test for this React component using Jest"
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.
This MCP server provides tools for frontend testing, including:
Code Analysis: Analyzes JavaScript/TypeScript code to determine appropriate testing strategies.
Test Generation: Generates unit and component tests for Jest and Cypress.
Test Running: Executes tests using Jest and Cypress and returns results.
Component Testing: Provides a tool specifically for testing React components.
Related MCP server: Frontend Code Analysis MCP
Clone the repository: `git clone mcp-frontend-testing`
Navigate to the project directory: `cd mcp-frontend-testing`
Install dependencies: `npm install`
```bash
npm run build
npm run start:http ```
```bash
npm run build
npm run start:stdio ```
analyzeCode: Analyzes code and returns analysis results.
Parameters:
`code` (string, required): The source code to analyze.
`language` (enum, optional): Language of the code (`javascript` | `typescript` | `jsx` | `tsx`, default: `javascript`).
generateTest: Generates test code based on source code and framework.
Parameters:
`code` (string, required): The source code to generate tests for.
`framework` (enum, required): Testing framework (`jest` | `cypress`).
`type` (enum, required): Type of test (`unit` | `component` | `e2e`).
`language` (enum, optional): Language of the code (`javascript` | `typescript` | `jsx` | `tsx`, default: `javascript`).
`description` (string, optional): Description of the test case.
runTest: Runs tests and returns results.
Parameters:
`sourceCode` (string, required): The source code being tested.
`testCode` (string, required): The test code to execute.
`framework` (enum, required): Testing framework (`jest` | `cypress`).
`type` (enum, required): Type of test (`unit` | `component` | `e2e`).
`config` (record, optional): Configuration object for test execution.
testReactComponent: Runs component tests specifically for React components.
Parameters:
`componentCode` (string, required): The source code of the React component.
`testCode` (string, optional): Test code for the component (auto-generated if not provided).
`framework` (enum, optional): Testing framework (`jest` | `cypress`, default: `jest`).
`props` (record, optional): Props to pass to the component during testing.
`autoGenerateTest` (boolean, optional): Automatically generate test code if not provided (default: `true`).
templates: Provides test templates.
URI: `templates://{framework}/{type}`
Parameters:
`framework` (string, required): Testing framework (`jest` | `cypress`).
`type` (string, required): Type of template (`unit` | `component`).
docs: Provides documentation for testing frameworks.
URI: `docs://{topic}`
Parameters:
`topic` (string, required): Documentation topic (`jest` | `cypress` | `react-testing-library`).
Build and run the server using Docker:
```bash docker build -t mcp-frontend-testing . docker run -p 3000:3000 mcp-frontend-testing ```
Deploy to cloud platforms like AWS Lambda, Google Cloud Run, or Azure Functions for serverless or containerized deployments.
Note: This server is designed to be used with an MCP client to enable LLMs to perform frontend testing tasks.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | ||
| language | No | javascript |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | ||
| description | No | ||
| framework | Yes | ||
| language | No | javascript | |
| type | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| config | No | ||
| framework | Yes | ||
| sourceCode | Yes | ||
| testCode | Yes | ||
| type | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| autoGenerateTest | No | ||
| componentCode | Yes | ||
| framework | No | jest | |
| props | No | ||
| testCode | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0analyzeCodegenerateTestrunTesttestReactComponentThe tools have some overlap in purpose, particularly 'generateTest' and 'testReactComponent' which both relate to testing, but they appear to target different scopes (general vs. React-specific). 'analyzeCode' and 'runTest' are more distinct, focusing on analysis and execution respectively. The lack of descriptions makes disambiguation more challenging but not impossible.
The naming is inconsistent with mixed conventions: 'analyzeCode', 'generateTest', and 'runTest' use camelCase, while 'testReactComponent' uses a different style that blends verb and noun without clear separation. There is no uniform pattern across all tools, making them less predictable and readable.
With 4 tools, the count is reasonable for a frontend testing server, as it covers key areas like analysis, test generation, execution, and component testing. It's slightly lean but appropriate for the apparent scope, avoiding bloat while providing essential functionality.
The tool set covers core testing workflows (analyze, generate, run, and component test), but there are notable gaps such as missing tools for mocking, debugging, or reporting results. Without descriptions, it's hard to assess full coverage, but the surface seems functional yet incomplete for comprehensive frontend testing.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Flaky test detection, root cause analysis, and fix suggestions for development teams.
Direct access to Cypress tests results and accessibility reports in your AI workflow.
Code intelligence platform for AI agents. 20 tools for architecture, security & impact analysis.
AI-powered codebase analysis — call graphs, security, dead code, complexity. 150+ tools.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/StudentOfJS/mcp-frontend-testing'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
