Claude Desktop, ChatGPT, Cursor 등과 같은 AI 클라이언트에 문법 검사, 글쓰기 개선, 번역 및 어조 조정 도구를 제공하는 MCP(Model Context Protocol) 서버입니다.
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 설정(~/Library/Application Support/Claude/claude_desktop_config.json, macOS 기준)에 추가하세요:
{
"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개의 단언(assertion)
모든 루프는 고정된 상한선을 가짐
전역 가변 상태 없음 (상수는 고정됨)
모든 반환 값은 검사됨
경고 제로
이 도구는 비원어민 영어 사용자를 위한 AI 기반 글쓰기 도구인 BeLikeNative 생태계의 일부입니다.
도구 | 유형 | 설명 |
GitHub Action | 60개의 규칙과 L1 인식 통찰력을 갖춘 PR 문법 검사기 | |
GitHub Action | 글쓰기 품질 분석: 가독성, 구조, 명확성 | |
GitHub Action | 국제화가 필요한 하드코딩된 문자열 찾기 | |
GitHub Action | 커밋 메시지 문법, 형식 및 명확성 검사기 | |
웹 도구 | 무료 웹사이트 성능 평가 도구 |
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.