Claude Desktop、ChatGPT、Cursor などの AI クライアントに、文法チェック、文章改善、翻訳、トーン調整ツールを提供する Model Context Protocol (MCP) サーバーです。
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つのアサーション
すべてのループには固定の上限を設定
グローバルな可変状態なし (定数は凍結)
すべての戻り値をチェック
警告ゼロ
このツールは、非ネイティブ英語話者向けの AI 駆動型ライティングツールエコシステム BeLikeNative の一部です。
ツール | タイプ | 説明 |
GitHub Action | 60のルールと L1 洞察を備えた PR 文法チェッカー | |
GitHub Action | 読みやすさ、構造、明瞭さに関する文章品質分析 | |
GitHub Action | 国際化が必要なハードコードされた文字列を検出 | |
GitHub Action | コミットメッセージの文法、形式、明瞭さチェッカー | |
Web ツール | 無料のウェブサイトパフォーマンス評価ツール |
BeLikeNative Chrome 拡張機能 — 100以上の言語、15のトーン、15のスタイルに対応した AI ライティングアシスタント。1万人以上のユーザー、評価 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.