Este servidor MCP proporciona herramientas para pruebas frontend, incluidas:
Análisis de código : analiza el código JavaScript/TypeScript para determinar estrategias de prueba adecuadas.
Generación de pruebas : genera pruebas unitarias y de componentes para Jest y Cypress.
Ejecución de pruebas : ejecuta pruebas utilizando Jest y Cypress y devuelve resultados.
Prueba de componentes : proporciona una herramienta específicamente para probar componentes React.
Related MCP server: Frontend Code Analysis MCP
Clonar el repositorio: `git clone mcp-frontend-testing`
Navegue al directorio del proyecto: `cd mcp-frontend-testing`
Instalar dependencias: `npm install`
``golpe
npm ejecutar compilación
npm ejecutar inicio:http ```
``golpe
npm ejecutar compilación
npm ejecutar inicio:stdio ```
AnalyzeCode : analiza el código y devuelve resultados del análisis.
Parámetros :
`code` (cadena, obligatoria): El código fuente a analizar.
`language` (enum, opcional): Idioma del código (`javascript` | `typescript` | `jsx` | `tsx`, predeterminado: `javascript`).
generateTest : genera código de prueba basado en el código fuente y el marco.
Parámetros :
`code` (cadena, obligatoria): el código fuente para el cual se generarán pruebas.
`framework` (enum, obligatorio): marco de prueba (`jest` | `cypress`).
`type` (enum, requerido): Tipo de prueba (`unit` | `component` | `e2e`).
`language` (enum, opcional): Idioma del código (`javascript` | `typescript` | `jsx` | `tsx`, predeterminado: `javascript`).
`description` (cadena, opcional): Descripción del caso de prueba.
runTest : ejecuta pruebas y devuelve resultados.
Parámetros :
`sourceCode` (cadena, obligatoria): el código fuente que se está probando.
`testCode` (cadena, obligatoria): el código de prueba a ejecutar.
`framework` (enum, obligatorio): marco de prueba (`jest` | `cypress`).
`type` (enum, requerido): Tipo de prueba (`unit` | `component` | `e2e`).
`config` (registro, opcional): objeto de configuración para la ejecución de pruebas.
testReactComponent : ejecuta pruebas de componentes específicamente para componentes React.
Parámetros :
`componentCode` (cadena, obligatoria): el código fuente del componente React.
`testCode` (cadena, opcional): Código de prueba para el componente (generado automáticamente si no se proporciona).
`framework` (enumeración, opcional): Marco de prueba (`jest` | `cypress`, predeterminado: `jest`).
`props` (registro, opcional): Propiedades que se pasarán al componente durante la prueba.
`autoGenerateTest` (booleano, opcional): genera automáticamente el código de prueba si no se proporciona (valor predeterminado: `true`).
plantillas : proporciona plantillas de prueba.
URI : `plantillas://{marco}/{tipo}`
Parámetros :
`framework` (cadena, obligatorio): marco de prueba (`jest` | `cypress`).
`type` (cadena, obligatorio): Tipo de plantilla (`unidad` | `componente`).
docs : proporciona documentación para probar marcos.
URI : `docs://{tema}`
Parámetros :
`topic` (cadena, obligatorio): Tema de documentación (`jest` | `cypress` | `react-testing-library`).
Construya y ejecute el servidor usando Docker:
```bash docker build -t mcp-frontend-testing .docker run -p 3000:3000 mcp-frontend-testing ```
Implemente en plataformas en la nube como AWS Lambda, Google Cloud Run o Azure Functions para implementaciones sin servidor o en contenedores.
Nota : Este servidor está diseñado para usarse con un cliente MCP para permitir que los LLM realicen tareas de pruebas de interfaz.
| 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.
v1.0.0analyzeCodegenerateTestrunTesttestReactComponentScored across 4 tools
The 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.
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.
No-code, AI-assisted UI testing: record new tests, run existing ones, and monitor the results.
Approved test intent, reviewed Playwright automation and run evidence, inside your editor.
