Ein Model Context Protocol (MCP)-Server, der Grammatikprüfung, Schreibverbesserung, Übersetzung und Tools zur Anpassung des Tonfalls für KI-Clients wie Claude Desktop, ChatGPT, Cursor und andere bereitstellt.
Kein API-Schlüssel erforderlich. Grammatik- und Stilprüfungen verwenden eine lokale regelbasierte Engine. Übersetzungs- und Tonfallanpassungen geben strukturierte Prompts für die verarbeitende Host-KI zurück.
Tool | Beschreibung | Verarbeitung |
| Überprüfung von Grammatik, Rechtschreibung und Zeichensetzung mit L1-bewussten Erklärungen | Lokal regelbasiert (50+ Regex-Regeln) |
| Analyse von Text auf Stil, Weitschweifigkeit, Passiv und Satzlänge | Lokal regelbasiert + Stilrichtlinien |
| Übersetzung von Text zwischen Sprachen mit natürlicher, flüssiger Ausgabe | Gibt Prompt für Host-KI zurück |
| Anpassung des Text-Tonfalls (formell, locker, professionell, diplomatisch usw.) | Gibt Prompt für Host-KI zurück |
Related MCP server: ukr-vitalinguist-mcp
Node.js 18+
Das ist alles. Keine API-Schlüssel, keine Umgebungsvariablen, keine externen Dienste.
cd mcp-server
pnpm installpnpm startDer Server kommuniziert über stdio (stdin/stdout). Er ist dafür konzipiert, von einem MCP-Client gestartet zu werden, nicht interaktiv ausgeführt zu werden.
Zur Claude Desktop-Konfiguration hinzufügen (~/Library/Application Support/Claude/claude_desktop_config.json unter macOS):
{
"mcpServers": {
"belikenative": {
"command": "node",
"args": ["/absolute/path/to/mcp-server/src/index.mjs"]
}
}
}Zu den Claude Code MCP-Einstellungen hinzufügen:
{
"mcpServers": {
"belikenative": {
"command": "node",
"args": ["/absolute/path/to/mcp-server/src/index.mjs"]
}
}
}Zur Cursor MCP-Konfiguration hinzufügen (.cursor/mcp.json in Ihrem Projekt oder ~/.cursor/mcp.json global):
{
"mcpServers": {
"belikenative": {
"command": "node",
"args": ["/absolute/path/to/mcp-server/src/index.mjs"]
}
}
}Jeder MCP-Client, der stdio-Transport unterstützt, kann diesen Server verwenden. Verweisen Sie ihn auf node src/index.mjs. Es sind keine Umgebungsvariablen erforderlich.
{
"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 für MCP)
Grammatik/Stil: Lokale regelbasierte Engine (keine externen API-Aufrufe)
Übersetzung/Tonfall: Gibt strukturierte Prompts für die verarbeitende Host-KI zurück
Logging: Alle Logs gehen an stderr (stdout ist für das MCP-Protokoll reserviert)
Fehlerbehandlung: Stürzt nie ab – alle Fehler geben strukturierte MCP-Fehlerantworten zurück
Die zentrale Erkenntnis: MCP-Tools werden von KI-Clients (Claude Desktop, Cursor usw.) aufgerufen, die bereits über eine integrierte KI verfügen. Es ist nicht erforderlich, dass der MCP-Server eigene API-Aufrufe tätigt.
check_grammar und improve_writing verwenden 50+ Regex-basierte Regeln, um Grammatikfehler, Rechtschreibfehler, Stilprobleme, Passivkonstruktionen und Probleme mit der Satzlänge zu erkennen. Die Ergebnisse sind deterministisch und sofort verfügbar.
translate und adjust_tone erfordern tatsächlich KI-Intelligenz, daher geben sie strukturierte Prompts mit Richtlinien zurück, die die Host-KI direkt verarbeitet. Dies ist schneller, kostengünstiger und zuverlässiger als ein doppelter API-Aufruf.
Dieser Server folgt den NASA Power of 10-Regeln:
Alle Funktionen unter 60 Zeilen
Mindestens 2 Assertionen pro Funktion
Alle Schleifen haben feste Obergrenzen
Kein globaler veränderbarer Zustand (Konstanten sind eingefroren)
Jeder Rückgabewert wird überprüft
Null Warnungen
Dieses Tool ist Teil des BeLikeNative-Ökosystems — KI-gestützte Schreibwerkzeuge für nicht-muttersprachliche Englischsprecher.
Tool | Typ | Beschreibung |
GitHub Action | PR-Grammatikprüfer mit 60 Regeln und L1-bewussten Erkenntnissen | |
GitHub Action | Analyse der Schreibqualität: Lesbarkeit, Struktur, Klarheit | |
GitHub Action | Findet hartcodierte Strings, die internationalisiert werden müssen | |
GitHub Action | Prüfer für Grammatik, Format & Klarheit von Commit-Nachrichten | |
Web-Tool | Kostenloser Website-Leistungsprüfer |
BeLikeNative Chrome-Erweiterung — KI-Schreibassistent für über 100 Sprachen, 15 Tonfälle, 15 Stile. 10.000+ Nutzer, 4,6★ Bewertung.
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.