The BeLikeNative Grammar Server is an MCP server that extends AI clients with text processing capabilities — no API key required.
check_grammar: Analyze text (up to 6,000 chars) for grammar, spelling, and punctuation errors using 50+ local regex rules, with L1-aware (native language-tailored) explanations — fully local, no API calls.
improve_writing: Evaluate text for wordiness, passive voice, and sentence length, with support for six target styles: academic, business, creative, technical, simple, or concise — processed locally.
translate: Generate a structured prompt for the host AI (e.g., Claude, Cursor) to translate text between any two languages.
adjust_tone: Provide transformation guidelines for the host AI to rewrite text in a desired tone — formal, casual, friendly, professional, persuasive, confident, empathetic, or diplomatic.
Grammar and writing tools run entirely locally for speed and privacy, while translation and tone adjustment offload AI-intensive work to the host client via carefully crafted prompts.
A Model Context Protocol (MCP) server that provides grammar checking, writing improvement, translation, and tone adjustment tools to AI clients like Claude Desktop, ChatGPT, Cursor, and others.
No API key required. Grammar and style checks use a local rule-based engine. Translation and tone adjustment return structured prompts for the host AI to process.
Tool | Description | Processing |
| Check grammar, spelling, and punctuation with L1-aware explanations | Local rule-based (50+ regex rules) |
| Analyze text for style, wordiness, passive voice, sentence length | Local rule-based + style guidelines |
| Translate text between languages with natural, fluent output | Returns prompt for host AI |
| Adjust text tone (formal, casual, professional, diplomatic, etc.) | Returns prompt for host AI |
Related MCP server: ukr-vitalinguist-mcp
Node.js 18+
That's it. No API keys, no environment variables, no external services.
cd mcp-server
pnpm installpnpm startThe server communicates via stdio (stdin/stdout). It is designed to be launched by an MCP client, not run interactively.
Add to your Claude Desktop config (~/Library/Application Support/Claude/claude_desktop_config.json on macOS):
{
"mcpServers": {
"belikenative": {
"command": "node",
"args": ["/absolute/path/to/mcp-server/src/index.mjs"]
}
}
}Add to your Claude Code MCP settings:
{
"mcpServers": {
"belikenative": {
"command": "node",
"args": ["/absolute/path/to/mcp-server/src/index.mjs"]
}
}
}Add to your Cursor MCP config (.cursor/mcp.json in your project or ~/.cursor/mcp.json globally):
{
"mcpServers": {
"belikenative": {
"command": "node",
"args": ["/absolute/path/to/mcp-server/src/index.mjs"]
}
}
}Any MCP client that supports stdio transport can use this server. Point it at node src/index.mjs. No environment variables needed.
{
"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)Transport: stdio (standard for MCP)
Grammar/Style: Local rule-based engine (no external API calls)
Translate/Tone: Returns structured prompts for the host AI client to process
Logging: All logs go to stderr (stdout is reserved for MCP protocol)
Error handling: Never crashes -- all errors return structured MCP error responses
The key insight: MCP tools are called by AI clients (Claude Desktop, Cursor, etc.) that already have AI built in. There is no need for the MCP server to make its own API calls.
check_grammar and improve_writing use 50+ regex-based rules to detect grammar errors, spelling mistakes, style issues, passive voice, and sentence length problems. Results are deterministic and instant.
translate and adjust_tone genuinely require AI intelligence, so they return structured prompts with guidelines that the host AI processes directly. This is faster, cheaper, and more reliable than a double API call.
This server follows NASA Power of 10 rules:
All functions under 60 lines
Minimum 2 assertions per function
All loops have fixed upper bounds
No global mutable state (constants are frozen)
Every return value is checked
Zero warnings
This tool is part of the BeLikeNative ecosystem — AI-powered writing tools for non-native English speakers.
Tool | Type | Description |
GitHub Action | PR grammar checker with 60 rules and L1-aware insights | |
GitHub Action | Writing quality analysis: readability, structure, clarity | |
GitHub Action | Find hardcoded strings that need internationalization | |
GitHub Action | Commit message grammar, format & clarity checker | |
Web Tool | Free website performance grader |
BeLikeNative Chrome Extension — AI writing assistant for 100+ languages, 15 tones, 15 styles. 10,000+ users, 4.6★ rating.
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.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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
Localization for AI agents: projects, languages, glossaries and translations from your agent
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/theluckystrike/bln-mcp-grammar-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
