frontend-dev-mcp es un servidor MCP orientado a escenarios de desarrollo frontend, cuyo objetivo es encapsular capacidades como la comprensión de la estructura del proyecto, la generación de tipos OpenAPI y la gestión de ingeniería de i18n en herramientas de IA estandarizadas, ayudando a los asistentes de IA a comprender mejor los repositorios frontend y asistiendo a los desarrolladores en tareas de ingeniería repetitivas.
Herramienta | Estado | Descripción |
| Implementado | Escanea JSON de locale y código fuente basado en AST de TypeScript, comprobando claves faltantes, claves no utilizadas y texto en chino codificado en JSX. |
| Implementado | Lee OpenAPI JSON/YAML, filtra operaciones por etiqueta y genera tipos de TypeScript y cliente fetch/axios. |
| Implementado | Identifica frameworks frontend, gestores de paquetes, rutas, directorios de módulos y archivos de configuración clave. |
Todas las herramientas devuelven de forma unificada:
{
content: [{ type: "text", text: result.summary }],
structuredContent: result
}Related MCP server: Text-Toolkit
TypeScript
MCP TypeScript SDK
zod/v3
stdio transport
Vitest
Instalar dependencias:
npm installIniciar el servidor MCP en modo desarrollo:
npm run devConstruir la versión de producción:
npm run buildIniciar el servidor construido:
npm run startEjecutar comprobación de tipos:
npm run typecheckEjecutar pruebas:
npm run testEjecutar solo pruebas a nivel de función de herramienta:
npm run test:unitEjecutar pruebas de integración MCP stdio después de la construcción:
npm run test:integrationDespués de la construcción, puede conectar el servidor como un servidor MCP stdio a clientes que soporten MCP.
Ejemplo de configuración:
{
"mcpServers": {
"frontend-dev-mcp": {
"command": "node",
"args": [
"C:/Users/wangqi/Downloads/frontend-dev-mcp/dist/index.js"
]
}
}
}En la fase de desarrollo también puede usar tsx para ejecutar el código fuente directamente:
{
"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[];
};Valores predeterminados:
rootDir: directorio de trabajo actual
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;
};Leer archivos de locale .json bajo localeDir.
Desplegar objetos de locale anidados en rutas de puntos, por ejemplo profile.title.
Identificar t("key") en el código fuente.
Identificar const key = "profile.title"; t(key) en el código fuente.
Identificar intl.formatMessage({ id: "key" }) en el código fuente.
Identificar <Trans i18nKey="key" /> en JSX.
Comprobar claves faltantes en otros idiomas basándose en defaultLocale.
Comprobar claves que existen en el locale pero no son referenciadas en el código fuente.
Comprobar texto en chino codificado en nodos de texto JSX, expresiones de cadena y atributos visibles, por ejemplo title, placeholder, alt, label.
Soporte para comentarios de ignorar:
A nivel de archivo: /* i18n-ignore-file */ o // i18n-ignore-file
A nivel de línea: // i18n-ignore o {/* i18n-ignore */}, ignora el uso de claves y el escaneo de texto codificado en la línea actual y la siguiente.
Ignorar el archivo completo:
/* i18n-ignore-file */
export function DebugPanel() {
return <button type="button">调试按钮</button>;
}Ignorar una sola línea o la siguiente:
// 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[];
};Valores predeterminados:
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;
};Leer OpenAPI JSON/YAML local o HTTP/HTTPS.
Leer components.schemas y generar types.ts.
Leer operaciones de paths y generar client.ts.
Generar tipos de parámetros de path/query/request body.
Integrar reemplazo de parámetros de path, parámetros de query y JSON request body en el cliente.
Soporte para estilos de cliente fetch y axios.
Soporte para filtrar operaciones con includeTags / excludeTags.
Soporte para generar archivos básicos de hooks de React Query cuando generateHooks = true.
Limitaciones actuales:
La capacidad de combinación de esquemas OpenAPI complejos es limitada, por ejemplo, oneOf, anyOf, allOf aún no están desplegados.
Los hooks generados requieren que el proyecto de negocio instale @tanstack/react-query por su cuenta.
type GetProjectStructureInput = {
rootDir?: string;
includeRoutes?: boolean;
includeModules?: boolean;
includeConfigs?: boolean;
maxDepth?: number;
};Valores predeterminados:
rootDir: directorio de trabajo actual
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;
};Identificar nextjs, vite-react, react, unknown.
Identificar pnpm, npm, yarn.
Escanear Next.js App Router: app/**/page.tsx, src/app/**/page.tsx.
Escanear Next.js Pages Router: pages/**/*.tsx, src/pages/**/*.tsx.
Escanear directorio de páginas React/Vite: src/pages/**/*.tsx.
Identificar directorios de módulos comunes: components, services, hooks, store, locales, i18n.
Identificar archivos de configuración clave: package.json, vite.config.*, next.config.*, tsconfig.json, ESLint, Prettier, configuración de Tailwind.
Herramienta: check_i18n_issues
Entrada:
{
"rootDir": "tests/fixtures/i18n-missing-keys",
"localeDir": "src/locales",
"defaultLocale": "en"
}Resumen de resultados esperados:
检测到 2 个语言资源：en, zh-CN；发现 2 个缺失 key；1 处硬编码文案；3 个未使用 key。Ejemplo de resultado estructurado:
{
"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"
}
]
}Herramienta: check_i18n_issues
Entrada:
{
"rootDir": "tests/fixtures/i18n-missing-keys",
"localeDir": "src/locales",
"defaultLocale": "en",
"checkMissingKeys": true,
"checkUnusedKeys": false,
"checkHardcodedText": false
}Adecuado para su uso en comprobaciones de CI donde solo importa la integridad de los recursos multilingües.
Herramienta: check_i18n_issues
Entrada:
{
"rootDir": "tests/fixtures/i18n-missing-keys",
"localeDir": "src/locales",
"include": ["src/**/*.{ts,tsx}"],
"exclude": [
"**/*.test.*",
"**/*.spec.*",
"**/node_modules/**",
"**/dist/**"
]
}Adecuado para excluir archivos de prueba, artefactos de construcción y directorios de dependencias en repositorios de negocio reales, reduciendo falsos positivos.
Herramienta: generate_api_types
Entrada:
{
"source": "tests/fixtures/openapi-basic/openapi.json",
"outputDir": "src/generated/api",
"clientStyle": "fetch",
"generateHooks": false,
"includeTags": ["user"]
}Resumen de resultados esperados:
从 tests/fixtures/openapi-basic/openapi.json 生成 1 个 schema、1 个 operation，输出 2 个文件到 src/generated/api。Archivos generados:
src/generated/api/
types.ts
client.tsHerramienta: get_project_structure
Entrada:
{
"rootDir": "tests/fixtures/vite-react-basic",
"includeRoutes": true,
"includeModules": true,
"includeConfigs": true,
"maxDepth": 4
}El resultado esperado devolverá el framework, gestor de paquetes, rutas, directorios de módulos, archivos de configuración clave y un resumen.
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.tsLos fixtures de prueba actuales cubren:
i18n-missing-keys: utilizado para verificar claves faltantes, claves no utilizadas y chino codificado.
openapi-basic: utilizado para pruebas posteriores de codegen de OpenAPI.
vite-react-basic: utilizado para pruebas posteriores de escaneo de estructura de proyecto Vite React.
next-app-router: utilizado para pruebas posteriores de escaneo de estructura de proyecto Next.js App Router.
Las pruebas se dividen en dos niveles:
Pruebas de integración a nivel de función: llaman directamente al manejador de herramientas en src/tools/*, verificando la lógica de negocio y la salida estructurada.
Pruebas de integración MCP stdio: inician el dist/index.js construido, llaman a la herramienta real a través del cliente MCP SDK, verificando el registro del servidor, el transporte y el formato de retorno.
check_i18n_issues: MVP completado.
generate_api_types: JSON/YAML, filtrado de etiquetas, parámetros básicos y generación de cuerpo de solicitud completados; posteriormente se añadirán esquemas complejos y hooks más completos.
get_project_structure: MVP completado; posteriormente se añadirá análisis AST de React Router, identificación de workspace de monorepo y escaneo de configuración más completo.
Para una descripción de diseño más completa, consulte 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