frontend-dev-mcp は、フロントエンド開発シナリオ向けの MCP Server です。プロジェクト構造の理解、OpenAPI 型生成、i18n エンジニアリング管理などの機能を標準化された AI Tools としてカプセル化し、AI アシスタントがフロントエンドリポジトリをより迅速に理解し、開発者が反復的なエンジニアリングタスクを処理するのを支援することを目的としています。
Tool | ステータス | 説明 |
| 実装済み | TypeScript AST に基づいて locale JSON とソースコードをスキャンし、欠落しているキー、未使用のキー、JSX 内のハードコードされた中国語テキストをチェックします。 |
| 実装済み | OpenAPI JSON/YAML を読み込み、タグで操作をフィルタリングし、TypeScript の型と fetch/axios クライアントを生成します。 |
| 実装済み | フロントエンドフレームワーク、パッケージマネージャー、ルーティング、モジュールディレクトリ、および重要な設定ファイルを識別します。 |
すべてのツールは以下を統一して返します：
{
content: [{ type: "text", text: result.summary }],
structuredContent: result
}Related MCP server: Text-Toolkit
TypeScript
MCP TypeScript SDK
zod/v3
stdio transport
Vitest
依存関係のインストール：
npm install開発モードで MCP Server を起動：
npm run dev本番ビルドの構築：
npm run buildビルド後のサーバーを起動：
npm run start型チェックの実行：
npm run typecheckテストの実行：
npm run testツール関数レベルのテストのみ実行：
npm run test:unitビルド後に MCP stdio 統合テストを実行：
npm run test:integrationビルド後、サーバーを stdio MCP server として MCP 対応クライアントに接続できます。
設定例：
{
"mcpServers": {
"frontend-dev-mcp": {
"command": "node",
"args": [
"C:/Users/wangqi/Downloads/frontend-dev-mcp/dist/index.js"
]
}
}
}開発段階では tsx を使用してソースコードを直接実行することも可能です：
{
"mcpServers": {
"frontend-dev-mcp": {
"command": "npx",
"args": [
"tsx",
"C:/Users/wangqi/Downloads/frontend-dev-mcp/src/index.ts"
]
}
}
}type CheckI18nIssuesInput = {
rootDir?: string;
localeDir?: string;
defaultLocale?: string;
checkHardcodedText?: boolean;
checkMissingKeys?: boolean;
checkUnusedKeys?: boolean;
include?: string[];
exclude?: string[];
};デフォルト値：
rootDir：現在の作業ディレクトリ
localeDir：src/locales
defaultLocale：en
checkHardcodedText：true
checkMissingKeys：true
checkUnusedKeys：true
include：["src/**/*.{ts,tsx,js,jsx}"]
exclude：["**/*.test.*", "**/*.spec.*", "**/node_modules/**", "**/dist/**"]
type CheckI18nIssuesOutput = {
localeDir: string;
locales: string[];
missingKeys: Array<{
locale: string;
key: string;
basedOn: string;
}>;
hardcodedTexts: Array<{
file: string;
text: string;
line?: number;
}>;
unusedKeys: Array<{
locale: string;
key: string;
}>;
summary: string;
};localeDir 下の .json locale ファイルを読み取ります。
ネストされた locale オブジェクトをドットパス（例：profile.title）に展開します。
ソースコード内の t("key") を識別します。
ソースコード内の const key = "profile.title"; t(key) を識別します。
ソースコード内の intl.formatMessage({ id: "key" }) を識別します。
JSX 内の <Trans i18nKey="key" /> を識別します。
defaultLocale を基準として、他の言語で欠落しているキーをチェックします。
locale には存在するがソースコードで参照されていないキーをチェックします。
JSX テキストノード、文字列式、および表示される属性（title、placeholder、alt、label など）内の中国語のハードコードされたテキストをチェックします。
ignore コメントをサポート：
ファイルレベル：/* i18n-ignore-file */ または // i18n-ignore-file
行レベル：// i18n-ignore または {/* i18n-ignore */}。現在の行と次の行のキー使用およびハードコードされたテキストスキャンを無視します。
ファイル全体を無視：
/* i18n-ignore-file */
export function DebugPanel() {
return <button type="button">调试按钮</button>;
}単一行または次の行を無視：
// i18n-ignore
const title = t("debug.title");
{/* i18n-ignore */}
<button type="button" title="临时按钮">临时保存</button>type GenerateApiTypesInput = {
source: string;
outputDir?: string;
clientStyle?: "fetch" | "axios";
generateHooks?: boolean;
includeTags?: string[];
excludeTags?: string[];
};デフォルト値：
outputDir：src/generated/api
clientStyle：fetch
generateHooks：false
type GenerateApiTypesOutput = {
source: string;
outputDir: string;
files: Array<{
path: string;
kind: "types" | "client" | "hooks";
}>;
operationsCount: number;
schemaCount: number;
summary: string;
};ローカルまたは HTTP/HTTPS の OpenAPI JSON/YAML を読み取ります。
components.schemas を読み取り、types.ts を生成します。
paths operations を読み取り、client.ts を生成します。
path/query/request body パラメータの型を生成します。
クライアント内で path パラメータの置換、query パラメータ、JSON request body を統合します。
fetch と axios の2つのクライアントスタイルをサポートします。
includeTags / excludeTags による operation のフィルタリングをサポートします。
generateHooks = true の場合、基本的な React Query hooks ファイルを生成します。
現在の制限：
複雑な OpenAPI スキーマの組み合わせ（oneOf、anyOf、allOf など）の展開は未対応です。
生成された hooks を使用するには、ビジネスプロジェクト側で @tanstack/react-query をインストールする必要があります。
type GetProjectStructureInput = {
rootDir?: string;
includeRoutes?: boolean;
includeModules?: boolean;
includeConfigs?: boolean;
maxDepth?: number;
};デフォルト値：
rootDir：現在の作業ディレクトリ
includeRoutes：true
includeModules：true
includeConfigs：true
maxDepth：4
type GetProjectStructureOutput = {
rootDir: string;
framework: "react" | "nextjs" | "vite-react" | "unknown";
packageManager: "npm" | "pnpm" | "yarn" | "unknown";
routes?: Array<{
path: string;
file: string;
kind: "page" | "layout" | "api" | "unknown";
}>;
modules?: Array<{
name: string;
path: string;
role: "pages" | "components" | "services" | "hooks" | "store" | "i18n" | "unknown";
}>;
configFiles?: Array<{
name: string;
path: string;
}>;
summary: string;
};nextjs、vite-react、react、unknown を識別します。
pnpm、npm、yarn を識別します。
Next.js App Router のスキャン：app/**/page.tsx、src/app/**/page.tsx。
Next.js Pages Router のスキャン：pages/**/*.tsx、src/pages/**/*.tsx。
React/Vite pages ディレクトリのスキャン：src/pages/**/*.tsx。
一般的なモジュールディレクトリの識別：components、services、hooks、store、locales、i18n。
重要な設定ファイルの識別：package.json、vite.config.*、next.config.*、tsconfig.json、ESLint、Prettier、Tailwind 設定。
Tool：check_i18n_issues
入力：
{
"rootDir": "tests/fixtures/i18n-missing-keys",
"localeDir": "src/locales",
"defaultLocale": "en"
}期待される結果の概要：
检测到 2 个语言资源：en, zh-CN；发现 2 个缺失 key；1 处硬编码文案；3 个未使用 key。構造化された結果の例：
{
"localeDir": "src/locales",
"locales": ["en", "zh-CN"],
"missingKeys": [
{
"locale": "zh-CN",
"key": "common.cancel",
"basedOn": "en"
},
{
"locale": "zh-CN",
"key": "profile.title",
"basedOn": "en"
}
],
"hardcodedTexts": [
{
"file": "src/App.tsx",
"text": "保存",
"line": 7
}
],
"unusedKeys": [
{
"locale": "en",
"key": "common.cancel"
},
{
"locale": "en",
"key": "common.submit"
},
{
"locale": "zh-CN",
"key": "common.submit"
}
]
}Tool：check_i18n_issues
入力：
{
"rootDir": "tests/fixtures/i18n-missing-keys",
"localeDir": "src/locales",
"defaultLocale": "en",
"checkMissingKeys": true,
"checkUnusedKeys": false,
"checkHardcodedText": false
}多言語リソースの完全性のみを重視する CI チェックに適しています。
Tool：check_i18n_issues
入力：
{
"rootDir": "tests/fixtures/i18n-missing-keys",
"localeDir": "src/locales",
"include": ["src/**/*.{ts,tsx}"],
"exclude": [
"**/*.test.*",
"**/*.spec.*",
"**/node_modules/**",
"**/dist/**"
]
}実際のビジネスリポジトリにおいて、テストファイル、ビルド成果物、依存関係ディレクトリを除外し、誤検知を減らすのに適しています。
Tool：generate_api_types
入力：
{
"source": "tests/fixtures/openapi-basic/openapi.json",
"outputDir": "src/generated/api",
"clientStyle": "fetch",
"generateHooks": false,
"includeTags": ["user"]
}期待される結果の概要：
从 tests/fixtures/openapi-basic/openapi.json 生成 1 个 schema、1 个 operation，输出 2 个文件到 src/generated/api。生成されたファイル：
src/generated/api/
types.ts
client.tsTool：get_project_structure
入力：
{
"rootDir": "tests/fixtures/vite-react-basic",
"includeRoutes": true,
"includeModules": true,
"includeConfigs": true,
"maxDepth": 4
}期待される結果として、フレームワーク、パッケージマネージャー、ルーティング、モジュールディレクトリ、重要な設定ファイル、およびサマリーが返されます。
frontend-dev-mcp/
docs/
technical-design.md
src/
index.ts
tools/
checkI18nIssues.ts
generateApiTypes.ts
getProjectStructure.ts
tests/
fixtures/
i18n-missing-keys/
next-app-router/
openapi-basic/
vite-react-basic/
checkI18nIssues.test.ts
generateApiTypes.test.ts
getProjectStructure.test.ts
package.json
tsconfig.json
vitest.config.ts現在のテストフィクスチャのカバー範囲：
i18n-missing-keys：欠落キー、未使用キー、ハードコードされた中国語の検証用。
openapi-basic：今後の OpenAPI codegen テスト用。
vite-react-basic：今後の Vite React プロジェクト構造スキャン用。
next-app-router：今後の Next.js App Router プロジェクト構造スキャン用。
テストは2層に分かれています：
関数レベルの統合テスト：src/tools/* 内のツールハンドラーを直接呼び出し、ビジネスロジックと構造化出力を検証します。
MCP stdio 統合テスト：ビルド後の dist/index.js を起動し、MCP SDK クライアントを通じて実際のツールを呼び出し、サーバーの登録、トランスポート、および戻り値の形式を検証します。
check_i18n_issues：MVP 完了。
generate_api_types：JSON/YAML、タグフィルタリング、基本的なパラメータとリクエストボディの生成は完了。今後は複雑なスキーマとより完全な hooks の対応予定。
get_project_structure：MVP 完了。今後は React Router AST 解析、monorepo workspace の識別、より完全な設定スキャンの対応予定。
より詳細な設計説明は docs/technical-design.md を参照してください。
Scan locale resources and source files for missing keys, unused keys, and hardcoded text.
| Name | Required | Description | Default |
|---|---|---|---|
| rootDir | No | ||
| localeDir | No | src/locales | |
| defaultLocale | No | en | |
| checkHardcodedText | No | ||
| checkMissingKeys | No | ||
| checkUnusedKeys | No | ||
| include | No | ||
| exclude | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the tool as scanning and checking, implying a read-only analysis. However, it doesn't disclose potential side effects (likely none), performance impact for large codebases, or error behavior. The description is adequate but not rich.
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?
The description is a single sentence listing the main actions, which is concise. It front-loades the purpose. It could be slightly more structured by separating the checks, but it's efficient.
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?
Given the parameter count (8) and no output schema, the description is insufficient. It doesn't explain the return format, how results are structured, or how to interpret failures. For a complex analysis tool, more context is needed for effective agent use.
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?
With 0% schema description coverage and 8 parameters, the description should compensate but does not. It mentions the three check types (missing keys, unused keys, hardcoded text), which map to three boolean parameters, but provides no details on rootDir, localeDir, defaultLocale, include, or exclude. The baseline is 3 due to low coverage, but the description adds only marginal value beyond the schema.
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?
The description clearly states the tool scans locale and source files for three specific issues: missing keys, unused keys, and hardcoded text. It uses a specific verb and resource, distinguishing it from siblings like generate_api_types and get_project_structure.
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?
The description does not provide any guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or context. The agent is left to infer usage from the parameter names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate TypeScript API types and client code from an OpenAPI spec.
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes | OpenAPI JSON/YAML file path or URL. | |
| outputDir | No | src/generated/api | |
| clientStyle | No | fetch | |
| generateHooks | No | ||
| includeTags | No | ||
| excludeTags | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description partially carries burden. It describes the behavior (generation from OpenAPI) but lacks details on file system changes, overwrite behavior, or network access for URLs.
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?
Single sentence, concise and front-loaded. Could include a bit more structure but efficient.
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?
With 6 params and no output schema, description could elaborate on return values or side effects. It's adequate but not complete for a code generation tool.
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?
Schema coverage is low (17%), but description doesn't add meaning beyond schema for most params. It provides general purpose but no detailed guidance on each parameter, so baseline 3.
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?
Description clearly states it generates TypeScript types and client code from OpenAPI spec. However, it doesn't distinguish from sibling tools like check_i18n_issues or get_project_structure, which are unrelated, so it's still clear.
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?
No explicit guidance on when to use this tool vs alternatives. Siblings are unrelated, so context is implied but no exclusions or alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze the frontend project structure, routes, modules, and key config files.
| Name | Required | Description | Default |
|---|---|---|---|
| rootDir | No | Project root directory. Defaults to the current working directory. | |
| includeRoutes | No | ||
| includeModules | No | ||
| includeConfigs | No | ||
| maxDepth | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. The description only mentions analysis of structure but does not specify if the tool is read-only, modifies state, or any side effects. It lacks details on output format or how deep the analysis goes, making behavior opaque.
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?
The description is a single sentence that is reasonably concise and front-loaded with the verb 'Analyze'. However, it could be slightly more structured by separating the purpose from the scope, but overall it is efficient.
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?
Given the complexity of 5 parameters and no output schema, the description is minimal but covers the general purpose. It lacks details on return values, error behavior, or prerequisites (e.g., Node.js project). The description is adequate for basic understanding but incomplete for reliable invocation.
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?
Schema description coverage is only 20%, meaning only rootDir has a description in the schema. The tool's description adds no parameter-specific meaning beyond the parameter names (e.g., includeRoutes, maxDepth). The description does not explain the semantics of boolean flags or depth constraints, so it fails to compensate for the low schema coverage.
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?
The description states the tool analyzes the frontend project structure, specifically routes, modules, and config files. It clearly indicates what the tool does but does not differentiate it from sibling tools like check_i18n_issues or generate_api_types, which are semantically distinct, so no confusion arises. However, the lack of differentiation slightly reduces the top score.
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?
The description implies the tool is for analyzing project structure but does not provide explicit guidance on when to use it versus alternatives. No when-not or exclusions are mentioned. The usage context is clear but not deeply prescriptive.
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.
v0.1.0check_i18n_issuesgenerate_api_typesget_project_structureScored across 3 tools
Each tool addresses a distinct frontend development concern: i18n checking, API type generation, and project structure analysis. There is no overlap in functionality.
All tool names follow a consistent verb_noun pattern (check_i18n_issues, generate_api_types, get_project_structure) using snake_case, making them predictable.
Three tools is minimal but appropriate for a focused frontend developer assistant covering common tasks. The scope feels slightly thin but not insufficient.
The tools cover i18n, API types, and project structure, but miss other common frontend tasks like linting, dependency checks, or component scaffolding. Some gaps exist but core utilities are present.
MCP Server for JFrog, providing tools for development and artifact management.
An MCP server that provides asset auto generator
MCP server for Product Management
MCP server for Translation Services