Click on "Deploy 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., "@mcp-i18n i18n翻译dashboard页面，basePath是/src/locale"
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.
基于 MCP (Model Context Protocol) 的页面级 i18n 翻译服务，使用阿里云百炼 Qwen 模型进行翻译。
按页面名称翻译，自动处理目录结构
支持 TypeScript 文件格式 (export default {})
内置术语表，保持专业术语翻译一致性
增量翻译，只翻译新增或修改的内容
默认翻译到 4 种语言：中文、日语、法语、德语
Related MCP server: @langapi/mcp-server
npm install
npm run build访问 阿里云百炼控制台 创建 API Key。
cp .env.example .env
# 编辑 .env 文件，填入 DASHSCOPE_API_KEY编辑配置文件：
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%/Claude/claude_desktop_config.json
{
"mcpServers": {
"i18n-translator": {
"command": "node",
"args": ["/path/to/mcp-i18n/dist/index.js"],
"env": {
"DASHSCOPE_API_KEY": "sk-your-api-key"
}
}
}
}在 Claude 对话中说：
i18n翻译mockupA页面，basePath是/packages/web/src/locale源文件位置：
{basePath}/{pageName}/en-US/
├── index.ts
└── other.ts生成的翻译文件：
{basePath}/{pageName}/
├── en-US/
│ └── index.ts # 源文件
├── zh-CN/
│ └── index.ts # 中文翻译
├── ja-JP/
│ └── index.ts # 日语翻译
├── fr-FR/
│ └── index.ts # 法语翻译
└── de-DE/
└── index.ts # 德语翻译源文件必须使用 export default 导出对象：
// en-US/index.ts
export default {
title: "Welcome to Pacdora",
description: "Create your custom packaging",
buttons: {
save: "Save",
cancel: "Cancel"
}
};生成的翻译文件：
// zh-CN/index.ts
export default {
title: "欢迎使用 Pacdora",
description: "创建您的定制包装",
buttons: {
save: "保存",
cancel: "取消"
}
};参数 | 必填 | 默认值 | 说明 |
| 是 | - | 页面名称，如 |
| 是 | - | locale 目录的基础路径 |
| 否 |
| 源语言代码 |
| 否 |
| 目标语言列表 |
| 否 |
| Qwen 模型 |
| 否 |
| 是否增量翻译 |
内置术语表确保专业术语翻译一致：
术语 | zh-CN | ja-JP | fr-FR | de-DE |
Pacdora | Pacdora | Pacdora | Pacdora | Pacdora |
Dieline | 刀板 | テンプレート | Gabarit | Stanzlinie |
修改 src/glossary.ts 可自定义术语表。
模型 | 特点 |
| 平衡性能和成本（默认） |
| 更高质量 |
| 最高质量 |
| 极速响应 |
mcp-i18n/
├── src/
│ ├── index.ts # MCP 服务器入口
│ ├── scanner.ts # 目录扫描和 TS 文件解析
│ ├── translator.ts # Qwen API 翻译引擎
│ ├── generator.ts # 翻译文件生成器
│ └── glossary.ts # 术语表
├── dist/ # 编译输出
└── package.jsonnpm run dev # 监听模式编译
npm run build # 编译
npm start # 运行服务MIT
Run 'pnpm check' in the specified directory to check i18n translation status. Use this when user wants to verify translation completeness.
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | No | Working directory to run the command in. Defaults to the current working directory. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that it executes `pnpm check` in a given directory and frames it as a status check. With no annotations provided, this gives some insight into the side-effect profile, but it does not describe output, failure behavior, or whether any files are modified.
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?
Two short sentences with the command and purpose front-loaded. Every word earns its place and there is no redundant detail.
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?
For a single-optional-parameter command tool with no output schema, the description covers what it does, where it runs, and when to use it. No essential detail for correct invocation appears to be missing.
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?
The schema already fully documents the only parameter (`cwd`) with its default behavior, so schema coverage is 100%. The description adds little beyond confirming that the check runs in the specified directory.
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?
Clearly identifies the action (run `pnpm check`), the target (specified directory), and the goal (check i18n translation status). It is easily distinguished from siblings `translate_page` and `show_glossary`, which perform translation or glossary tasks rather than verification.
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?
States an explicit trigger: use when the user wants to verify translation completeness. It does not mention exclusions or alternatives, so it stops short of a full when/when-not comparison with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export the built-in glossary/terminology dictionary. Use this when user wants to view or check the translation glossary. Optionally filter by locale.
| Name | Required | Description | Default |
|---|---|---|---|
| locale | No | Optional locale code to filter (e.g., 'zh-CN'). If omitted, returns all locales. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only export operation, which is useful behavioral context given no annotations. However, it does not disclose the return format, pagination, or any limits, which would add more transparency.
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?
Two sentences with no wasted words. The key action and usage context are front-loaded, and the optional filtering behavior is stated concisely.
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?
For a simple one-optional-parameter tool, the description covers purpose, usage context, and filtering. The main gap is the lack of return format detail, but the output is implied to be the glossary/terminology dictionary.
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?
The schema already describes the locale parameter fully, and description adds only a brief 'Optionally filter by locale' without adding new semantic detail. Baseline 3 is appropriate given the 100% 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 uses a specific verb and resource: 'Export the built-in glossary/terminology dictionary.' It clearly tells an agent what the tool does and differentiates it from the sibling tools translate_page and check-i18n by focusing on viewing/checking the glossary rather than translating or checking i18n.
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?
Explicitly states when to use: 'Use this when user wants to view or check the translation glossary.' It provides clear context though it does not explicitly mention alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Translate a specific page's locale files. Use this when user says 'i18n翻译{pageName}页面'. Reads from {basePath}/{pageName}/en-US/ and creates translations in zh-CN, ja-JP, fr-FR, de-DE directories.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Qwen model to use (default: qwen-turbo) | qwen-turbo |
| apiKey | No | DashScope API key (optional, can use env var DASHSCOPE_API_KEY) | |
| basePath | Yes | Base path to locale directory (e.g., '/packages/web/src/locale') | |
| pageName | Yes | Name of the page to translate (e.g., 'mockupA') | |
| incremental | No | Only translate new/modified keys (default: true) | |
| sourceLocale | No | Source locale code (default: en-US) | en-US |
| targetLocales | No | Target locale codes (default: zh-CN, ja-JP, fr-FR, de-DE) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the behavioral burden. It discloses the main I/O behavior: reads from '/en-US/' and creates translations in target locale directories. However, it does not mention that the tool invokes an LLM (despite model/apiKey parameters), whether it overwrites existing files, or if it requires network/API access. These are meaningful behavioral gaps for a mutation tool.
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 two sentences with no filler. The primary purpose and trigger are front-loaded in the first sentence, and the path structure is conveyed compactly in the second. Every clause contributes useful information.
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?
The tool has 7 parameters and no output schema, so the description needs to provide enough context for correct invocation. It covers the trigger, paths, and target locales well, but it omits any hint about return values or what success looks like, and it does not mention the model/API dependency implied by the schema. With high schema coverage the gaps are moderate, earning a middling score.
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 100%, so the baseline is 3. The description adds semantic value by showing the relationship between basePath and pageName through the path template '{basePath}/{pageName}/en-US/' and by listing the exact target locale directories, which reinforces the meaning of targetLocales. This goes slightly beyond merely repeating schema descriptions.
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 opens with a specific verb and resource: 'Translate a specific page's locale files.' It clearly distinguishes from siblings by focusing on translation of a single page's locale files, while check-i18n suggests verification and show_glossary suggests display. The trigger phrase 'i18n翻译{pageName}页面' further anchors the exact use case.
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 explicitly states when to use this tool: 'Use this when user says i18n翻译{pageName}页面'. This is a clear triggering condition. It does not explicitly name alternatives or exclusion cases, but the trigger phrase alone provides sufficient guidance for an agent to select it over the sibling tools.
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.
v1.0.0check-i18nshow_glossarytranslate_pageScored across 3 tools
Each tool has a clearly distinct purpose: translating a page, checking translation status, and viewing the glossary. There is no meaningful overlap that would cause an agent to select the wrong tool.
Two tools follow a verb_noun snake_case pattern, but 'check-i18n' breaks the pattern with a hyphen and abbreviated domain term. The mixed conventions are still readable, but the naming is not fully consistent.
Three tools is well-scoped for an i18n-focused server. Each tool covers a distinct part of the workflow and none feel redundant or unnecessary.
The core workflow of translating pages, verifying completeness, and consulting the glossary is covered. Minor gaps like glossary editing or batch translation exist, but they are not obvious blockers for typical i18n tasks.
MCP server for Translation Services
MCP server for Crowdin — projects, files, strings, translation progress, tasks, and members.
Lingo.dev MCP Server - World-class i18n implementation with ICU MessageFormat.
Phrase MCP server: language intelligence platform for translation, terminology, and quality.
