この 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` (列挙型、オプション): コードの言語 (`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. 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
