frontend-dev-mcp는 프론트엔드 개발 환경을 위한 MCP 서버로, 프로젝트 구조 파악, OpenAPI 타입 생성, i18n 엔지니어링 관리 등의 기능을 표준화된 AI 도구로 캡슐화하여 AI 어시스턴트가 프론트엔드 저장소를 더 빠르게 이해하고 반복적인 엔지니어링 작업을 돕도록 설계되었습니다.
도구 | 상태 | 설명 |
| 구현 완료 | 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 서버 실행:
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 서버로 사용하여 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 작업을 읽고 client.ts를 생성합니다.
path/query/request body 매개변수 타입을 생성합니다.
클라이언트 내에서 path 매개변수 교체, query 매개변수 및 JSON request body를 지원합니다.
fetch 및 axios 두 가지 클라이언트 스타일을 지원합니다.
includeTags / excludeTags를 통한 작업 필터링을 지원합니다.
generateHooks = true 설정 시 기본적인 React Query 훅 파일을 생성합니다.
현재 제한 사항:
복잡한 OpenAPI 스키마 조합(예: oneOf, anyOf, allOf)은 아직 확장되지 않습니다.
생성된 훅을 사용하려면 비즈니스 프로젝트에서 @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 설정.
도구: 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"
}
]
}도구: check_i18n_issues
입력:
{
"rootDir": "tests/fixtures/i18n-missing-keys",
"localeDir": "src/locales",
"defaultLocale": "en",
"checkMissingKeys": true,
"checkUnusedKeys": false,
"checkHardcodedText": false
}다국어 리소스의 무결성만 확인하는 CI 검사에 적합합니다.
도구: check_i18n_issues
입력:
{
"rootDir": "tests/fixtures/i18n-missing-keys",
"localeDir": "src/locales",
"include": ["src/**/*.{ts,tsx}"],
"exclude": [
"**/*.test.*",
"**/*.spec.*",
"**/node_modules/**",
"**/dist/**"
]
}실제 비즈니스 저장소에서 테스트 파일, 빌드 산출물 및 의존성 디렉토리를 제외하여 오탐을 줄이는 데 적합합니다.
도구: 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.ts도구: 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현재 테스트 fixture 범위:
i18n-missing-keys: 누락된 키, 사용되지 않는 키 및 하드코딩된 중국어 검증용.
openapi-basic: 향후 OpenAPI codegen 테스트용.
vite-react-basic: 향후 Vite React 프로젝트 구조 스캔 테스트용.
next-app-router: 향후 Next.js App Router 프로젝트 구조 스캔 테스트용.
테스트는 두 계층으로 나뉩니다:
함수 단위 통합 테스트: src/tools/*의 도구 핸들러를 직접 호출하여 비즈니스 로직과 구조화된 출력을 검증합니다.
MCP stdio 통합 테스트: 빌드된 dist/index.js를 실행하고 MCP SDK 클라이언트를 통해 실제 도구를 호출하여 서버 등록, 전송 및 반환 형식을 검증합니다.
check_i18n_issues: MVP 완료.
generate_api_types: JSON/YAML, 태그 필터링, 기본 매개변수 및 요청 본문 생성 완료; 향후 복잡한 스키마 및 더 완전한 훅 지원 예정.
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