该 MCP 服务器提供前端测试工具，包括：
代码分析：分析 JavaScript/TypeScript 代码以确定适当的测试策略。
测试生成：为 Jest 和 Cypress 生成单元和组件测试。
测试运行：使用 Jest 和 Cypress 执行测试并返回结果。
组件测试：提供专门用于测试 React 组件的工具。
Related MCP server: Frontend Code Analysis MCP
克隆存储库： `git clone mcp-frontend-testing`
导航到项目目录： `cd mcp-frontend-testing`
安装依赖项： `npm install`
```bash
npm 运行构建
npm 运行开始：http ```
```bash
npm 运行构建
npm 运行开始：stdio ```
analyzeCode ：分析代码并返回分析结果。
参数：
`code`（字符串，必需）：要分析的源代码。
`language`（枚举，可选）：代码的语言（`javascript` | `typescript` | `jsx` | `tsx`，默认值：`javascript`）。
generateTest ：根据源代码和框架生成测试代码。
参数：
`code`（字符串，必需）：生成测试的源代码。
`framework`（枚举，必需）：测试框架（`jest` | `cypress`）。
`type` (枚举，必需)：测试类型 (`unit` | `component` | `e2e`)。
`language`（枚举，可选）：代码的语言（`javascript` | `typescript` | `jsx` | `tsx`，默认值：`javascript`）。
`description`（字符串，可选）：测试用例的描述。
runTest ：运行测试并返回结果。
参数：
`sourceCode`（字符串，必需）：正在测试的源代码。
`testCode`（字符串，必需）：要执行的测试代码。
`framework`（枚举，必需）：测试框架（`jest` | `cypress`）。
`type` (枚举，必需)：测试类型 (`unit` | `component` | `e2e`)。
`config`（记录，可选）：测试执行的配置对象。
testReactComponent ：专门针对 React 组件运行组件测试。
参数：
`componentCode`（字符串，必需）：React 组件的源代码。
`testCode`（字符串，可选）：组件的测试代码（如果未提供则自动生成）。
`framework` （枚举，可选）：测试框架（`jest` | `cypress`，默认值：`jest`）。
`props`（记录，可选）：测试期间传递给组件的道具。
`autoGenerateTest`（布尔值，可选）：如果未提供，则自动生成测试代码（默认值：`true`）。
templates ：提供测试模板。
URI ：`templates://{framework}/{type}`
参数：
`framework`（字符串，必需）：测试框架（`jest` | `cypress`）。
`type` (字符串，必需)：模板类型 (`unit` | `component`)。
docs ：提供测试框架的文档。
URI ：`docs://{topic}`
参数：
`topic` (字符串，必需)：文档主题 (`jest` | `cypress` | `react-testing-library`)。
使用 Docker 构建并运行服务器：
```bash docker build -t mcp-frontend-testing.docker run -p 3000:3000 mcp-frontend-testing```
部署到 AWS Lambda、Google Cloud Run 或 Azure Functions 等云平台，实现无服务器或容器化部署。
注意：此服务器设计用于与 MCP 客户端一起使用，以使 LLM 能够执行前端测试任务。
| 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.
