一个模型上下文协议 (MCP) 服务器，为 Claude Desktop、ChatGPT、Cursor 等 AI 客户端提供语法检查、写作改进、翻译和语气调整工具。
无需 API 密钥。 语法和风格检查使用本地基于规则的引擎。翻译和语气调整功能会返回结构化提示词，供宿主 AI 处理。
工具 | 描述 | 处理方式 |
| 检查语法、拼写和标点，并提供 L1 语言感知解释 | 本地基于规则（50+ 条正则表达式规则） |
| 分析文本的风格、冗长程度、被动语态、句子长度 | 本地基于规则 + 风格指南 |
| 在不同语言间进行翻译，输出自然流畅 | 返回给宿主 AI 的提示词 |
| 调整文本语气（正式、随意、专业、外交辞令等） | 返回给宿主 AI 的提示词 |
Related MCP server: ukr-vitalinguist-mcp
Node.js 18+
仅此而已。无需 API 密钥，无需环境变量，无需外部服务。
cd mcp-server
pnpm installpnpm start服务器通过 stdio (stdin/stdout) 进行通信。它旨在由 MCP 客户端启动，而非交互式运行。
添加到您的 Claude Desktop 配置中（macOS 上位于 ~/Library/Application Support/Claude/claude_desktop_config.json）：
{
"mcpServers": {
"belikenative": {
"command": "node",
"args": ["/absolute/path/to/mcp-server/src/index.mjs"]
}
}
}添加到您的 Claude Code MCP 设置中：
{
"mcpServers": {
"belikenative": {
"command": "node",
"args": ["/absolute/path/to/mcp-server/src/index.mjs"]
}
}
}添加到您的 Cursor MCP 配置中（项目内的 .cursor/mcp.json 或全局的 ~/.cursor/mcp.json）：
{
"mcpServers": {
"belikenative": {
"command": "node",
"args": ["/absolute/path/to/mcp-server/src/index.mjs"]
}
}
}任何支持 stdio 传输的 MCP 客户端都可以使用此服务器。将其指向 node src/index.mjs。无需环境变量。
{
"text": "string (required, max 6000 chars)",
"language": "string (optional, default 'en') -- writer's native language for L1-tailored explanations"
}{
"text": "string (required, max 6000 chars)",
"style": "enum: academic | business | creative | technical | simple | concise (optional, default 'business')"
}{
"text": "string (required, max 6000 chars)",
"source_language": "string (required) -- e.g. 'en', 'English', 'fr'",
"target_language": "string (required) -- e.g. 'es', 'Spanish', 'de'"
}{
"text": "string (required, max 6000 chars)",
"tone": "enum: formal | casual | friendly | professional | persuasive | confident | empathetic | diplomatic (required)"
}src/
index.mjs -- MCP server entry point (stdio transport, tool registration)
tools.mjs -- Tool definitions (JSON schemas) and handler functions
rules.mjs -- Local grammar rules engine (50+ regex patterns, style analyzer)传输: stdio (MCP 标准)
语法/风格: 本地基于规则的引擎（无外部 API 调用）
翻译/语气: 返回结构化提示词供宿主 AI 客户端处理
日志: 所有日志输出到 stderr (stdout 保留给 MCP 协议)
错误处理: 永不崩溃 —— 所有错误均返回结构化的 MCP 错误响应
核心洞察：MCP 工具由已经内置 AI 的 AI 客户端（Claude Desktop、Cursor 等）调用。MCP 服务器无需自行进行 API 调用。
check_grammar 和 improve_writing 使用 50 多条基于正则表达式的规则来检测语法错误、拼写错误、风格问题、被动语态和句子长度问题。结果是确定性的且即时的。
translate 和 adjust_tone 确实需要 AI 智能，因此它们返回带有指南的结构化提示词，由宿主 AI 直接处理。这比双重 API 调用更快、更便宜且更可靠。
此服务器遵循 NASA Power of 10 规则：
所有函数不超过 60 行
每个函数至少有 2 个断言
所有循环都有固定的上限
无全局可变状态（常量已冻结）
检查每个返回值
零警告
此工具是 BeLikeNative 生态系统的一部分 —— 为非英语母语者提供的 AI 写作工具。
工具 | 类型 | 描述 |
GitHub Action | 带有 60 条规则和 L1 语言感知洞察的 PR 语法检查器 | |
GitHub Action | 写作质量分析：可读性、结构、清晰度 | |
GitHub Action | 查找需要国际化的硬编码字符串 | |
GitHub Action | 提交信息语法、格式和清晰度检查器 | |
Web 工具 | 免费网站性能评分工具 |
BeLikeNative Chrome 扩展程序 —— 适用于 100 多种语言、15 种语气、15 种风格的 AI 写作助手。拥有 10,000 多名用户，4.6 星评分。
MIT
Returns structured tone adjustment guidelines and a prompt for the host AI to process. The MCP server provides tone rules and transformation guidance -- the host AI performs the rewrite. Powered by BeLikeNative.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The text whose tone to adjust (max 6000 chars). | |
| tone | Yes | Desired tone. One of: formal, casual, friendly, professional, persuasive, confident, empathetic, diplomatic. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully convey behavior. It discloses the key behavioral trait that the host AI performs the rewrite, not the tool itself. However, it does not disclose other aspects like idempotency, side effects, or required permissions.
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 three sentences, with the first two providing core functionality. The third sentence ('Powered by BeLikeNative') is extraneous but not harmful. It is front-loaded and relatively concise.
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 no output schema and 2 parameters, the description explains the output nature (guidelines + prompt) but does not detail structure or provide examples. It is adequate but leaves gaps for an agent to use it effectively.
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 100%, so baseline is 3. The description does not add additional meaning beyond the schema's parameter descriptions (e.g., text max length, tone enum values). No further elaboration on usage or format.
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 explicitly states that the tool returns structured tone adjustment guidelines and a prompt, and clarifies that the actual rewrite is performed by the host AI. This clearly distinguishes it from sibling tools like check_grammar (grammar) and translate (language).
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 use for tone adjustment but does not provide explicit guidance on when to use this tool over siblings like improve_writing or check_grammar. No prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check grammar, spelling, and punctuation using local rule-based analysis. Returns structured JSON with errors found, corrections, and L1-aware explanations. No API calls needed. Powered by BeLikeNative.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The text to check for grammar errors (max 6000 chars). | |
| language | No | The writer's native language (L1) for tailored explanations. ISO 639-1 code or language name. Default: "en". | en |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses it is rule-based and local, and provides L1-aware explanations, but lacks details on limitations (e.g., language support beyond default) or return format specifics.
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?
Three sentences, each adding value: what it does, what it returns, and key differentiators (no API, powered by BeLikeNative). No unnecessary words.
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 two-parameter tool with no output schema, the description is nearly complete. It explains the return structure (structured JSON with errors, corrections, explanations) and the purpose of each parameter.
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 100%, and description adds value by explaining the 'language' parameter is used for 'L1-aware explanations' and 'text' is the content to check. This goes beyond the schema description.
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 checks grammar, spelling, and punctuation using local rule-based analysis, and returns structured JSON with errors and corrections. It is distinct from sibling tools like adjust_tone and improve_writing.
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. The description mentions 'No API calls needed' which implies offline use, but does not provide when-to-use or when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze text for writing quality using rule-based style checks. Returns structured suggestions covering wordiness, passive voice, sentence length, and style-specific guidelines. No API calls needed. Powered by BeLikeNative.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The text to improve (max 6000 chars). | |
| style | No | Target writing style. One of: academic, business, creative, technical, simple, concise. Default: "business". | business |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so description must disclose behavior. It mentions 'rule-based style checks' and 'No API calls needed', giving insight into how it operates. However, it does not address potential limitations or side effects.
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 very concise, consisting of a few short sentences that each add unique value. No redundancy or wasted words.
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 tool with two parameters and no output schema, the description provides a good overview of what it does and what it returns. However, it lacks details on the exact structure of the suggestions, which would improve completeness.
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?
Both parameters are fully described in the input schema (100% coverage). The description adds no new semantic information about the parameters beyond what the schema provides.
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 analyzes text for writing quality using rule-based checks and returns suggestions. It distinguishes from siblings implicitly (adjust_tone, check_grammar, translate) but does not explicitly differentiate.
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 guidance on when to use this tool vs alternatives. The description does not mention when not to use it or provide context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a structured translation prompt for the host AI to process. The MCP server provides formatting and context -- the host AI performs the actual translation. Powered by BeLikeNative.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The text to translate (max 6000 chars). | |
| source_language | Yes | Source language. ISO 639-1 code or full name (e.g. "en", "English", "fr", "French"). | |
| target_language | Yes | Target language. ISO 639-1 code or full name (e.g. "es", "Spanish", "de", "German"). |
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 discloses that the tool does not perform translation itself but returns a prompt for the host AI, which is a key behavioral trait. However, it does not describe any side effects, authentication requirements, rate limits, or error conditions, leaving gaps in 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?
The description consists of two efficient sentences. The first sentence immediately states the core function, and the second provides context about the MCP server's role. No redundant words or unnecessary details are present.
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 tool with three required parameters and no output schema or annotations, the description is mostly complete. It explains the output (structured translation prompt) and the division of labor with the host AI. However, it could benefit from mentioning the prompt format or an example, especially given the lack of output schema.
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 schema already provides meaning for all three parameters (text, source_language, target_language). The description adds no additional parameter-specific information beyond what the schema states, resulting in a baseline score of 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?
The description clearly states the tool returns a structured translation prompt and that the MCP server provides formatting/context while the host AI performs the actual translation. It differentiates from sibling tools (adjust_tone, check_grammar, improve_writing) which address different tasks. However, it does not use a single verb+resource phrase, slightly reducing clarity.
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 should be used when translation is needed, but the host AI handles the actual translation. It does not explicitly state when to use versus alternatives or provide case exclusions. Usage context is implied rather than explicitly guided.
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.0adjust_tonecheck_grammarimprove_writingtranslateScored across 4 tools
Each tool has a clearly distinct purpose: grammar checking, style improvement, tone adjustment, and translation. No overlapping functionality, so an agent can easily select the correct tool.
All tools follow a consistent verb_noun pattern (adjust_tone, check_grammar, improve_writing, translate), with the last being a conventional single-verb name. No mixed styles or confusing variations.
With 4 tools, the set is well-scoped for a grammar/language server. Each tool addresses a core language task without unnecessary bloat or deficiency.
The tools cover essential language assistance: grammar/spelling, style improvement, tone adjustment, and translation. No obvious gaps for the stated domain of a grammar server.
Sentiment, toxicity, entity extraction, PII, translation, summary, QA, fraud scoring, safety audit.
Toxicity, sentiment, NER, PII detection, and language identification tools
Prose linter + AI-slop detector: weasel words, passive voice, hedging, and research-cited AI tells
Multilingual AI workspace: 1,000+ prompts, Compare Mode, 35 languages, BYOM. Free trial.