frontend-dev-mcp 是一个面向前端研发场景的 MCP Server，目标是把项目结构理解、OpenAPI 类型生成、i18n 工程治理等能力封装成标准化 AI Tools，帮助 AI 助手更快理解前端仓库，并辅助开发者处理重复性工程任务。
Tool | 状态 | 说明 |
| 已实现 | 基于 TypeScript AST 扫描 locale JSON 和源码，检查缺失 key、未使用 key、JSX 硬编码中文文案。 |
| 已实现 | 读取 OpenAPI JSON/YAML，按 tag 过滤 operations，生成 TypeScript types 和 fetch/axios client。 |
| 已实现 | 识别前端框架、包管理器、路由、模块目录和关键配置文件。 |
所有工具统一返回：
{
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启动构建后的 server：
npm run start运行类型检查：
npm run typecheck运行测试：
npm run test只运行 tool 函数级测试：
npm run test:unit构建后运行 MCP stdio 集成测试：
npm run test:integration构建后可以将 server 作为 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 为基准检查其他语言缺失的 key。
检查 locale 中存在但源码未引用的 key。
检查 JSX 文本节点、字符串表达式和可见属性中的中文硬编码文案，例如 title、placeholder、alt、label。
支持 ignore 注释：
文件级：/* i18n-ignore-file */ 或 // i18n-ignore-file
行级：// i18n-ignore 或 {/* i18n-ignore */}，忽略当前行和下一行的 key 使用与硬编码文案扫描。
忽略整个文件：
/* 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 参数类型。
在 client 中接入 path 参数替换、query 参数和 JSON request body。
支持 fetch 和 axios 两种 client 风格。
支持 includeTags / excludeTags 过滤 operation。
支持 generateHooks = true 时生成基础 React Query hooks 文件。
当前限制：
复杂 OpenAPI schema 组合能力有限，例如 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
}预期结果会返回框架、包管理器、路由、模块目录、关键配置文件和 summary。
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当前测试 fixture 覆盖：
i18n-missing-keys：用于验证缺失 key、未使用 key 和硬编码中文。
openapi-basic：用于后续 OpenAPI codegen 测试。
vite-react-basic：用于后续 Vite React 项目结构扫描。
next-app-router：用于后续 Next.js App Router 项目结构扫描。
测试分为两层：
函数级集成测试：直接调用 src/tools/* 中的 tool handler，验证业务逻辑和结构化输出。
MCP stdio 集成测试：启动构建后的 dist/index.js，通过 MCP SDK client 调用真实 tool，验证 server 注册、transport 和返回格式。
check_i18n_issues：已完成 MVP。
generate_api_types：已完成 JSON/YAML、tag 过滤、基础参数和请求体生成；后续补复杂 schema 和更完整 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