Generates an Axios-based API client from OpenAPI specifications.
Detects ESLint configuration files as part of project structure scanning.
Scans Next.js App Router and Pages Router projects to detect routes, layouts, and API files, and identifies the framework as nextjs.
Detects npm as a package manager in project structure scanning.
Detects pnpm as a package manager in project structure scanning.
Detects Prettier configuration files as part of project structure scanning.
Scans React projects to detect framework setup, routes, modules, and configuration files; also checks for i18n issues and hardcoded Chinese text in JSX.
Optionally generates React Query hooks for API operations when generateHooks is enabled.
Planned future support for React Router AST-based route scanning (mentioned in development roadmap).
Generates TypeScript types from OpenAPI schemas, including path/query/body parameter types, and uses TypeScript AST for i18n scanning.
Scans Vite + React projects to identify routes, modules, and config files like vite.config.*.
Used for testing the MCP server (implementation detail, but explicitly listed in Tech Stack).
Reads OpenAPI YAML files for API type generation.
Detects Yarn as a package manager in project structure scanning.
Used as part of the MCP server's technical stack for input validation (though it is an implementation detail, it is listed explicitly in the Tech Stack).
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@frontend-dev-mcp check i18n issues in the current project with default settings"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
frontend-dev-mcp is an MCP Server designed for frontend development scenarios. Its goal is to encapsulate capabilities such as project structure understanding, OpenAPI type generation, and i18n engineering governance into standardized AI Tools, helping AI assistants understand frontend repositories faster and assisting developers with repetitive engineering tasks.
Tool | Status | Description |
| Implemented | Scans locale JSON and source code based on TypeScript AST to check for missing keys, unused keys, and hardcoded Chinese text in JSX. |
| Implemented | Reads OpenAPI JSON/YAML, filters operations by tag, and generates TypeScript types and fetch/axios clients. |
| Implemented | Identifies frontend frameworks, package managers, routing, module directories, and key configuration files. |
All tools return the following uniformly:
{
content: [{ type: "text", text: result.summary }],
structuredContent: result
}Related MCP server: Text-Toolkit
TypeScript
MCP TypeScript SDK
zod/v3
stdio transport
Vitest
Install dependencies:
npm installStart the MCP Server in development mode:
npm run devBuild the production version:
npm run buildStart the built server:
npm run startRun type checking:
npm run typecheckRun tests:
npm run testRun only tool function-level tests:
npm run test:unitRun MCP stdio integration tests after building:
npm run test:integrationAfter building, you can connect the server as a stdio MCP server to clients that support MCP.
Example configuration:
{
"mcpServers": {
"frontend-dev-mcp": {
"command": "node",
"args": [
"C:/Users/wangqi/Downloads/frontend-dev-mcp/dist/index.js"
]
}
}
}During the development phase, you can also use tsx to run the source code directly:
{
"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[];
};Default values:
rootDir: Current working directory
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;
};Reads .json locale files under localeDir.
Flattens nested locale objects into dot-notation paths, e.g., profile.title.
Identifies t("key") in source code.
Identifies const key = "profile.title"; t(key) in source code.
Identifies intl.formatMessage({ id: "key" }) in source code.
Identifies <Trans i18nKey="key" /> in JSX.
Checks for missing keys in other languages based on defaultLocale.
Checks for keys that exist in locale files but are not referenced in the source code.
Checks for hardcoded Chinese text in JSX text nodes, string expressions, and visible attributes, such as title, placeholder, alt, and label.
Supports ignore comments:
File-level: /* i18n-ignore-file */ or // i18n-ignore-file
Line-level: // i18n-ignore or {/* i18n-ignore */}, ignores key usage and hardcoded text scanning for the current and next line.
Ignore an entire file:
/* i18n-ignore-file */
export function DebugPanel() {
return <button type="button">调试按钮</button>;
}Ignore a single line or the next line:
// 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[];
};Default values:
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;
};Reads local or HTTP/HTTPS OpenAPI JSON/YAML.
Reads components.schemas and generates types.ts.
Reads paths operations and generates client.ts.
Generates types for path/query/request body parameters.
Integrates path parameter replacement, query parameters, and JSON request body in the client.
Supports both fetch and axios client styles.
Supports includeTags / excludeTags for operation filtering.
Supports generating basic React Query hooks files when generateHooks = true.
Current limitations:
Limited support for complex OpenAPI schema combinations, e.g., oneOf, anyOf, allOf are not yet expanded.
Generated hooks require the business project to install @tanstack/react-query independently.
type GetProjectStructureInput = {
rootDir?: string;
includeRoutes?: boolean;
includeModules?: boolean;
includeConfigs?: boolean;
maxDepth?: number;
};Default values:
rootDir: Current working directory
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;
};Identifies nextjs, vite-react, react, unknown.
Identifies pnpm, npm, yarn.
Scans Next.js App Router: app/**/page.tsx, src/app/**/page.tsx.
Scans Next.js Pages Router: pages/**/*.tsx, src/pages/**/*.tsx.
Scans React/Vite pages directory: src/pages/**/*.tsx.
Identifies common module directories: components, services, hooks, store, locales, i18n.
Identifies key configuration files: package.json, vite.config.*, next.config.*, tsconfig.json, ESLint, Prettier, Tailwind configurations.
Tool: check_i18n_issues
Input:
{
"rootDir": "tests/fixtures/i18n-missing-keys",
"localeDir": "src/locales",
"defaultLocale": "en"
}Expected result summary:
检测到 2 个语言资源：en, zh-CN；发现 2 个缺失 key；1 处硬编码文案；3 个未使用 key。Structured result example:
{
"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
Input:
{
"rootDir": "tests/fixtures/i18n-missing-keys",
"localeDir": "src/locales",
"defaultLocale": "en",
"checkMissingKeys": true,
"checkUnusedKeys": false,
"checkHardcodedText": false
}Suitable for use in CI checks where only the integrity of multilingual resources is a concern.
Tool: check_i18n_issues
Input:
{
"rootDir": "tests/fixtures/i18n-missing-keys",
"localeDir": "src/locales",
"include": ["src/**/*.{ts,tsx}"],
"exclude": [
"**/*.test.*",
"**/*.spec.*",
"**/node_modules/**",
"**/dist/**"
]
}Suitable for excluding test files, build artifacts, and dependency directories in actual business repositories to reduce false positives.
Tool: generate_api_types
Input:
{
"source": "tests/fixtures/openapi-basic/openapi.json",
"outputDir": "src/generated/api",
"clientStyle": "fetch",
"generateHooks": false,
"includeTags": ["user"]
}Expected result summary:
从 tests/fixtures/openapi-basic/openapi.json 生成 1 个 schema、1 个 operation，输出 2 个文件到 src/generated/api。Generated files:
src/generated/api/
types.ts
client.tsTool: get_project_structure
Input:
{
"rootDir": "tests/fixtures/vite-react-basic",
"includeRoutes": true,
"includeModules": true,
"includeConfigs": true,
"maxDepth": 4
}Expected results will return the framework, package manager, routing, module directories, key configuration files, and a 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.tsCurrent test fixtures cover:
i18n-missing-keys: Used to verify missing keys, unused keys, and hardcoded Chinese.
openapi-basic: Used for subsequent OpenAPI codegen testing.
vite-react-basic: Used for subsequent Vite React project structure scanning.
next-app-router: Used for subsequent Next.js App Router project structure scanning.
Tests are divided into two layers:
Function-level integration tests: Directly call tool handlers in src/tools/* to verify business logic and structured output.
MCP stdio integration tests: Start the built dist/index.js, call real tools via the MCP SDK client to verify server registration, transport, and return format.
check_i18n_issues: MVP completed.
generate_api_types: JSON/YAML, tag filtering, basic parameter and request body generation completed; complex schemas and more complete hooks to be added later.
get_project_structure: MVP completed; React Router AST parsing, monorepo workspace identification, and more complete configuration scanning to be added later.
For a more complete design description, see 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.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/bhaltair/frontend-dev-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server