이 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`
```배쉬
npm 실행 빌드
npm 실행 시작:http ```
```배쉬
npm 실행 빌드
npm 실행 시작:stdio ```
analyzeCode : 코드를 분석하고 분석 결과를 반환합니다.
매개변수 :
`code` (문자열, 필수): 분석할 소스 코드.
`language` (enum, 선택 사항): 코드의 언어(`javascript` | `typescript` | `jsx` | `tsx`, 기본값: `javascript`).
generateTest : 소스 코드와 프레임워크를 기반으로 테스트 코드를 생성합니다.
매개변수 :
`code` (문자열, 필수): 테스트를 생성할 소스 코드입니다.
`framework` (enum, 필수): 테스트 프레임워크(`jest` | `cypress`).
`type` (enum, 필수): 테스트 유형(`unit` | `component` | `e2e`).
`language` (enum, 선택 사항): 코드의 언어(`javascript` | `typescript` | `jsx` | `tsx`, 기본값: `javascript`).
`description` (문자열, 선택 사항): 테스트 사례에 대한 설명입니다.
runTest : 테스트를 실행하고 결과를 반환합니다.
매개변수 :
`sourceCode` (문자열, 필수): 테스트 중인 소스 코드.
`testCode` (문자열, 필수): 실행할 테스트 코드.
`framework` (enum, 필수): 테스트 프레임워크(`jest` | `cypress`).
`type` (enum, 필수): 테스트 유형(`unit` | `component` | `e2e`).
`config` (레코드, 선택 사항): 테스트 실행을 위한 구성 객체.
testReactComponent : React 구성 요소에 대한 구성 요소 테스트를 실행합니다.
매개변수 :
`componentCode` (문자열, 필수): React 컴포넌트의 소스 코드.
`testCode`(문자열, 선택 사항): 구성 요소에 대한 테스트 코드(제공되지 않으면 자동 생성됨).
`framework`(열거형, 선택 사항): 테스트 프레임워크(`jest` | `cypress`, 기본값: `jest`).
`props`(레코드, 선택 사항): 테스트 중에 구성 요소에 전달할 속성입니다.
`autoGenerateTest` (boolean, 선택 사항): 제공되지 않으면 자동으로 테스트 코드를 생성합니다(기본값: `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-프런트엔드-테스팅 . docker run -p 3000:3000 mcp-프런트엔드-테스팅 ```
AWS Lambda, Google Cloud Run 또는 Azure Functions와 같은 클라우드 플랫폼에 배포하여 서버리스 또는 컨테이너화된 배포를 구현합니다.
참고 : 이 서버는 LLM이 프런트엔드 테스트 작업을 수행할 수 있도록 MCP 클라이언트와 함께 사용하도록 설계되었습니다.
| 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
