The Nativ MCP server integrates AI-powered localization into AI coding assistants, leveraging translation memory (TM), brand voice, and style guides.
Translate text (translate): Translate text to a target language with support for context, glossary, formality, character limits, and back-translation.
Batch translate (translate_batch): Translate multiple strings to a single target language in one call — ideal for i18n files or UI label lists.
Search translation memory (search_translation_memory): Fuzzy-search existing translations by language and minimum score to ensure consistency.
Add to translation memory (add_translation_memory_entry): Store approved translations for automatic reuse in future localizations.
Get configured languages (get_languages): Retrieve all workspace languages, including formality settings and custom style directives.
Get TM stats (get_translation_memory_stats): View total entries, enabled/disabled counts, and breakdown by source type.
Get style guides (get_style_guides): Access all configured style guides, including content and enabled status.
Get brand voice (get_brand_voice): Retrieve the master brand voice prompt defining tone, personality, and localization guidelines.
Use guided prompts: Follow structured workflows for content localization, translation review, and batch string localization.
Supports the localization of Markdown documents and content, ensuring consistency with established style guides and translation memory.
mcp-name: io.github.Nativ-Technologies/nativ
AI-powered localization for any MCP-compatible tool — Claude Code, Cursor, Windsurf, and more.
Nativ is a localization platform that uses AI to translate content while respecting your brand voice, translation memory, glossaries, and style guides. This MCP server brings Nativ's full localization engine into your AI coding workflow.
Translate in-context — localize strings, copy, and content directly from your editor without switching to a browser
Translation Memory aware — every translation checks your TM first, ensuring consistency across your project
Brand voice built-in — your team's tone, formality, and style guides are applied automatically
Review and approve — add approved translations to TM from your editor, building quality over time
Multi-format — JSON, CSV, Markdown, or freeform text — Nativ handles it all
Related MCP server: i1n
Sign up at dashboard.usenativ.com, go to Settings → API Keys, and create a key. It looks like nativ_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.
Add to your MCP configuration:
~/.claude/claude_desktop_config.json){
"mcpServers": {
"nativ": {
"command": "npx",
"args": ["-y", "nativ-mcp"],
"env": {
"NATIV_API_KEY": "nativ_your_api_key_here"
}
}
}
}.cursor/mcp.json in your project or ~/.cursor/mcp.json globally){
"mcpServers": {
"nativ": {
"command": "npx",
"args": ["-y", "nativ-mcp"],
"env": {
"NATIV_API_KEY": "nativ_your_api_key_here"
}
}
}
}{
"mcpServers": {
"nativ": {
"command": "npx",
"args": ["-y", "nativ-mcp"],
"env": {
"NATIV_API_KEY": "nativ_your_api_key_here"
}
}
}
}Note:
npxauto-downloads the package on first run — no manual install needed. Ifuvisn't already on your machine, it will be installed automatically on first launch.If you already have
uvinstalled and prefer to skip the npm wrapper:{ "mcpServers": { "nativ": { "command": "uvx", "args": ["nativ-mcp"], "env": { "NATIV_API_KEY": "nativ_your_api_key_here" } } } }macOS tip: If you get
spawn uvx ENOENTin Cursor or Claude Desktop, GUI apps don't inherit your shell PATH. Use the full path (e.g."command": "/Users/you/.local/bin/uvx") or wrap in a login shell:"command": "/bin/sh", "args": ["-lc", "uvx nativ-mcp"].
Ask your AI assistant things like:
"Translate 'Welcome back!' to French and German"
"Check our translation memory for existing translations of 'Sign up'"
"What are our style guides for localization?"
"Localize these i18n strings to all configured languages"
"Review this German translation against our TM and brand voice"
Tool | Description |
| Translate text using the full localization engine (TM, style guides, brand voice, glossary) |
| Translate multiple texts to a target language in one call |
| Fuzzy-search the translation memory for existing translations |
| Add an approved translation to TM for future reuse |
| List all configured languages with formality and style settings |
| Get TM statistics — total entries, sources, and breakdown |
| List all style guides with their content and status |
| Get the brand voice prompt that shapes all translations |
| Extract on-image text segments (OCR) in reading order |
| Replace on-image text with translations in place, keeping layout and graphics intact |
| Flag cultural-sensitivity issues in an image across target markets |
URI | Description |
| Configured languages (JSON) |
| All style guides (JSON) |
| Brand voice prompt (JSON) |
| Translation memory statistics (JSON) |
Prompt | Description |
| Guided workflow to localize content into target languages |
| Review a translation against TM, style guides, and brand voice |
| Batch-localize i18n strings with structured output |
You: Translate "The future of luxury, delivered" to French and Japanese
AI: [calls translate tool for each language]
Translation (French): "L'avenir du luxe, livré chez vous"
TM Match: 0% — new translation, no prior TM entries
Rationale: "Livré chez vous" adds a personal touch absent from the literal
"livré", aligning with the brand's premium yet approachable voice.
Translation (Japanese): "ラグジュアリーの未来を、あなたの元へ"
TM Match: 45% partial — similar pattern found in TM from brand_voice sourceYou: Do we have translations for "Add to cart" in our TM?
AI: [calls search_translation_memory]
TM Search Results for "Add to cart" (3 matches):
- 95% [strong] "Add to cart" → "Ajouter au panier" (source: approved)
- 95% [strong] "Add to cart" → "In den Warenkorb" (source: brand_voice)
- 72% [partial] "Add items to cart" → "Ajouter des articles" (source: phrase_tm)You: Localize these to French:
- "Sign up"
- "Log in"
- "Forgot password?"
- "Continue with Google"
AI: [calls translate_batch]
Batch translation to French (4 items):
1. "Sign up" → "S'inscrire" (TM 100%)
2. "Log in" → "Se connecter" (TM 100%)
3. "Forgot password?" → "Mot de passe oublié ?" (TM 92%)
4. "Continue with Google" → "Continuer avec Google" (TM 85%)Environment Variable | Required | Description |
| Yes | Your Nativ API key ( |
| No | API base URL (defaults to |
This MCP server acts as a bridge between your AI coding assistant and the Nativ API:
┌─────────────────────┐ ┌──────────────┐ ┌─────────────────┐
│ Claude / Cursor / │────▶│ Nativ MCP │────▶│ Nativ API │
│ Windsurf / etc. │◀────│ Server │◀────│ (Translation, │
│ │ │ (stdio) │ │ TM, Styles) │
└─────────────────────┘ └──────────────┘ └─────────────────┘The MCP server runs locally via stdio. It authenticates with your API key and calls the Nativ REST API on your behalf. Your AI assistant sees Nativ's tools, resources, and prompts as native capabilities.
# Clone the repo
git clone https://github.com/nativ-ai/nativ-mcp.git
cd nativ-mcp
# Set up environment
uv venv
source .venv/bin/activate
uv pip install -e .
# Run the server (for testing)
NATIV_API_KEY=nativ_xxx nativ-mcp
# Run with MCP Inspector
NATIV_API_KEY=nativ_xxx npx @modelcontextprotocol/inspector uv run nativ-mcpMIT — see LICENSE.
Add a new entry to the translation memory.
Use this to store approved translations so they are reused in future localizations.
Args: source_text: The original text. target_text: The approved translation. source_language_code: Source language code (e.g. "en"). target_language_code: Target language code (e.g. "fr-FR"). name: Optional label for this entry (e.g. "homepage hero copy").
| Name | Required | Description | Default |
|---|---|---|---|
| source_text | Yes | ||
| target_text | Yes | ||
| source_language_code | Yes | ||
| target_language_code | Yes | ||
| name | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 indicates this is a write operation ('Add'), but doesn't disclose behavioral traits like permissions needed, whether entries are immutable, rate limits, or error conditions. The description adds value by explaining the purpose of storing for reuse, but lacks operational details.
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 appropriately sized and well-structured: a brief purpose statement, usage guideline, then parameter explanations in a clear 'Args:' section. Every sentence earns its place, with no redundant or vague phrasing.
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 the tool has an output schema (which handles return values), no annotations, and 5 parameters with 0% schema coverage, the description does well by covering purpose, usage, and parameter semantics. However, it lacks behavioral context (e.g., mutation effects, error handling) that would be important for a write operation without annotations.
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 0%, so the description must compensate. It provides clear semantics for all 5 parameters, explaining what each represents (e.g., 'source_text: The original text', 'target_text: The approved translation') with examples for language codes and the optional name. This adds significant meaning beyond the bare schema.
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's purpose with specific verb ('Add') and resource ('new entry to the translation memory'), and distinguishes it from siblings by focusing on storage rather than retrieval or translation. The second sentence explains the functional goal ('store approved translations so they are reused'), making the purpose unambiguous.
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 explicitly states when to use this tool ('Use this to store approved translations so they are reused in future localizations'), providing clear context. It implicitly distinguishes from siblings like 'search_translation_memory' (for retrieval) and 'translate' (for translation), though it doesn't name alternatives directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the brand voice prompt — the core localization personality.
This is the master prompt that shapes all translations. It captures the brand's tone, personality, terminology, and localization guidelines.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It indicates this is a read operation ('Get') and describes what the tool returns (the brand voice prompt with its components). However, it doesn't disclose important behavioral traits like whether authentication is required, rate limits, error conditions, or whether the data is cached/live. The description adds some context about what the prompt contains but misses operational details.
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 appropriately sized with three sentences that each add value: stating the action, explaining the tool's importance as the 'master prompt', and detailing what the prompt captures. It's front-loaded with the core purpose. Minor improvement could come from slightly tighter phrasing, but overall it's efficient.
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 the tool's simplicity (0 parameters, output schema exists), the description provides adequate context. It explains what the tool retrieves and its significance in the localization system. With an output schema handling return value documentation, the description focuses appropriately on purpose and context rather than output details. For a zero-parameter read tool, this is reasonably complete.
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?
The tool has 0 parameters with 100% schema description coverage, so the baseline is 4. The description appropriately doesn't discuss parameters since none exist, focusing instead on what the tool returns. This is efficient and avoids unnecessary information.
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's purpose with specific verbs ('Get the brand voice prompt') and identifies the resource ('core localization personality', 'master prompt'). It distinguishes this tool from siblings by specifying it retrieves the foundational localization personality rather than performing translations, managing languages, or accessing style guides.
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 usage context by stating this is 'the master prompt that shapes all translations', suggesting it should be used to understand localization guidelines before performing translation tasks. However, it doesn't explicitly state when to use this tool versus alternatives like get_style_guides or translate, nor does it provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all languages configured for the Nativ workspace.
Returns language names, codes, formality settings, and custom style directives for each language.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 returns language data (names, codes, etc.), which is useful behavioral context. However, it lacks details on permissions, rate limits, error handling, or whether it's a read-only operation (implied but not stated). The description adds some value but leaves gaps in behavioral traits.
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 concise and well-structured: two sentences that front-load the purpose and detail the return values. Every sentence earns its place by providing essential information without redundancy. It efficiently communicates the tool's function and output.
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 the tool's low complexity (0 parameters) and the presence of an output schema, the description is reasonably complete. It explains what the tool does and what it returns, which is sufficient for the agent. However, it could improve by addressing usage context or behavioral aspects like permissions, but the output schema likely covers return values, reducing the burden.
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?
The tool has 0 parameters, and the input schema has 100% description coverage (though empty). The description doesn't need to add parameter semantics, so it appropriately focuses on output. A baseline of 4 is justified as it compensates for the lack of parameters by detailing the return data, which is helpful for the agent.
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's purpose: 'Get all languages configured for the Nativ workspace.' It specifies the verb ('Get') and resource ('languages'), and distinguishes it from siblings like 'translate' or 'get_style_guides' by focusing on workspace language configurations. However, it doesn't explicitly differentiate from all siblings (e.g., 'get_brand_voice' might also retrieve configurations).
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context for usage, or comparisons to sibling tools like 'get_style_guides' or 'get_brand_voice'. The agent must infer usage based on the purpose alone, which is insufficient for optimal tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all style guides configured for the workspace.
Returns the titles, content, and enabled status of each style guide.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds value by specifying the return content ('titles, content, and enabled status'), which helps the agent understand what to expect. However, it lacks details on potential limitations like pagination, rate limits, or authentication needs, which are important for a read operation.
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 front-loaded with the core purpose in the first sentence and adds useful output details in the second. Both sentences earn their place by providing essential information without redundancy, making it efficient and well-structured.
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 the tool's simplicity (0 parameters, no annotations, but has an output schema), the description is reasonably complete. It explains what the tool does and what it returns, which is sufficient for a basic read operation. However, it could be more comprehensive by addressing behavioral aspects like error handling or data freshness, slightly reducing the score.
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?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, focusing instead on the tool's purpose and output. This meets the baseline for tools with no parameters, as it avoids unnecessary details.
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's purpose with a specific verb ('Get') and resource ('all style guides configured for the workspace'), making it easy to understand what it does. However, it doesn't explicitly differentiate from sibling tools like 'get_brand_voice' or 'get_languages', which might also retrieve workspace configurations, so it misses the highest score.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention any context, prerequisites, or exclusions, such as whether it's for administrative purposes or general use, leaving the agent to infer usage from the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get statistics about the translation memory.
Shows total entries, enabled/disabled counts, and breakdown by source type.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states this is a 'Get' operation, implying read-only behavior, but doesn't explicitly confirm safety aspects like non-destructive nature or permission requirements. It mentions the types of statistics returned but doesn't describe format, potential rate limits, or error conditions. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
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 perfectly concise and well-structured: a clear purpose statement followed by specific details about what statistics are included. Both sentences earn their place by adding valuable information without redundancy. The front-loaded purpose statement immediately communicates the tool's function.
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 the tool's simplicity (0 parameters, read-only operation) and the presence of an output schema, the description is minimally adequate. It explains what statistics are retrieved, which complements the output schema. However, for a tool with no annotations, it could better address behavioral aspects like safety guarantees or typical use cases to be more complete.
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?
The tool has 0 parameters with 100% schema description coverage (empty schema). The description doesn't need to compensate for any parameter documentation gaps. It appropriately doesn't mention parameters since none exist, earning a high baseline score for not introducing confusion about non-existent inputs.
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's purpose: 'Get statistics about the translation memory' with specific details about what statistics are included (total entries, enabled/disabled counts, breakdown by source type). It distinguishes itself from siblings like 'search_translation_memory' or 'add_translation_memory_entry' by focusing on statistical retrieval rather than search or modification operations. However, it doesn't explicitly contrast with all siblings, so it doesn't reach the highest score.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, context for usage, or comparisons with sibling tools like 'search_translation_memory' or 'get_languages'. The agent must infer usage from the purpose alone, which is insufficient for optimal tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the translation memory for existing translations.
Use this to check if translations already exist before creating new ones, or to find reference translations for consistency.
Args: query: Text to search for in the translation memory. source_language_code: Source language code (default: "en"). target_language_code: Optional target language code to filter results. min_score: Minimum fuzzy match score (0-100). Default 0 returns all. limit: Maximum number of results (default 10).
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| source_language_code | No | en | |
| target_language_code | No | ||
| min_score | No | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 describes the tool as a search function, implying it's read-only and non-destructive, which is adequate for basic transparency. However, it lacks details on behavioral traits like rate limits, authentication needs, error handling, or how results are returned (e.g., format, pagination), leaving gaps in understanding the tool's operation.
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 well-structured and appropriately sized. It starts with a clear purpose sentence, followed by usage guidelines, and then a parameter section with concise explanations. Every sentence adds value without redundancy, and the information is front-loaded for quick understanding.
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 5 parameters with 0% schema coverage and an output schema present, the description does a good job of compensating. It explains all parameters thoroughly and provides usage context. The output schema likely covers return values, so the description doesn't need to detail them. However, it could improve by mentioning sibling tools for better integration, but overall, it's quite complete for a search tool.
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 0%, so the description must fully compensate. It provides detailed semantics for all 5 parameters: explains 'query' as text to search, 'source_language_code' with default, 'target_language_code' as optional filter, 'min_score' as fuzzy match range, and 'limit' as result maximum. This adds significant meaning beyond the bare schema, making parameters clear and actionable.
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's purpose: 'Search the translation memory for existing translations.' It specifies the verb ('search') and resource ('translation memory'), making the function unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'get_translation_memory_stats' or 'translate', which could help avoid confusion.
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 provides clear usage context: 'Use this to check if translations already exist before creating new ones, or to find reference translations for consistency.' This gives practical scenarios for when to use the tool. It doesn't explicitly state when not to use it or name alternatives among siblings, but the guidance is helpful for typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Translate text using Nativ's AI localization engine.
Uses the team's translation memory, style guides, and brand voice automatically. Returns the translation along with TM match info and rationale.
Args: text: The text to translate. target_language: Full target language name (e.g. "French", "German", "Japanese"). target_language_code: Optional ISO language code (e.g. "fr", "de", "ja"). source_language: Source language name. Defaults to English. source_language_code: Source language code. Defaults to "en". context: Optional context to guide the translation (e.g. "marketing headline for Gen Z audience"). glossary: Optional inline glossary as CSV (e.g. "term,translation\nbrand,marque"). formality: Tone override — one of: very_informal, informal, neutral, formal, very_formal. max_characters: Optional strict character limit for the translation output. backtranslate: If true, also returns a back-translation to verify intent.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| target_language | Yes | ||
| target_language_code | No | ||
| source_language | No | English | |
| source_language_code | No | en | |
| context | No | ||
| glossary | No | ||
| formality | No | ||
| max_characters | No | ||
| backtranslate | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well by disclosing behavioral traits: it explains the engine uses team resources (translation memory, style guides, brand voice), returns additional info (TM match, rationale), and supports back-translation for verification. It lacks details on rate limits or error handling.
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 appropriately sized and front-loaded with the core purpose, followed by a structured parameter list. Every sentence adds value, though the parameter section is lengthy but necessary given the complexity. Minor room for tightening introductory text.
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 the tool's complexity (10 parameters, no annotations) and the presence of an output schema, the description is largely complete: it covers purpose, behavioral context, and parameter semantics. It could improve by mentioning output structure or error cases, but the output schema likely handles return values.
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 0%, so the description must compensate fully. It provides detailed semantics for all 10 parameters, including examples (e.g., 'French', 'fr'), defaults (e.g., source language defaults to English), and usage guidance (e.g., context for audience targeting). This adds significant value beyond the bare schema.
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's purpose as translating text using Nativ's AI localization engine, specifying it leverages translation memory, style guides, and brand voice. It distinguishes from siblings like 'translate_batch' (batch processing) and 'search_translation_memory' (searching rather than translating).
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 usage for AI-powered translation with contextual enhancements but does not explicitly state when to use this tool versus alternatives like 'translate_batch' for batch operations or 'search_translation_memory' for lookup. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Translate multiple texts to a single target language.
Useful for localizing lists of strings, UI labels, or i18n files. Each text is translated individually using the team's TM and style guides.
Args: texts: List of texts to translate. target_language: Full target language name (e.g. "French"). target_language_code: Optional ISO language code. source_language: Source language name. Defaults to English. source_language_code: Source language code. Defaults to "en". context: Optional context to guide all translations. formality: Tone override for all translations.
| Name | Required | Description | Default |
|---|---|---|---|
| texts | Yes | ||
| target_language | Yes | ||
| target_language_code | No | ||
| source_language | No | English | |
| source_language_code | No | en | |
| context | No | ||
| formality | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds valuable context: 'Each text is translated individually using the team's TM and style guides,' revealing reliance on translation memory and style guides. However, it lacks details on permissions, rate limits, error handling, or what the output contains. For a mutation tool (translation implies creation of translated content) with zero annotation coverage, this is a moderate gap.
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 appropriately sized and front-loaded: the first sentence states the core purpose, followed by usage context and behavioral details, then a structured parameter list. Every sentence earns its place with no redundancy or waste. The 'Args' section is well-organized for easy reference.
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 the tool's complexity (7 parameters, no annotations, but with an output schema), the description is fairly complete. It covers purpose, usage, behavioral context, and parameter semantics. The output schema existence means return values needn't be explained, but for a mutation tool with no annotations, more behavioral details (e.g., side effects, error cases) would enhance 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?
Schema description coverage is 0%, so the description must compensate. It provides a detailed 'Args' section explaining all 7 parameters, adding meaning beyond the schema's titles. For example, it clarifies that 'target_language' expects a 'Full target language name (e.g. "French"),' and notes defaults for source language parameters. However, it doesn't explain parameter interactions or constraints (e.g., if both language name and code are provided).
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's purpose: 'Translate multiple texts to a single target language.' It specifies the verb ('translate'), resource ('multiple texts'), and scope ('to a single target language'), distinguishing it from the sibling 'translate' tool which presumably handles single translations. The description further clarifies use cases: 'localizing lists of strings, UI labels, or i18n files.'
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 provides clear context for when to use this tool: 'Useful for localizing lists of strings, UI labels, or i18n files.' It implies batch translation scenarios but does not explicitly state when NOT to use it or name alternatives like the sibling 'translate' tool for single translations. The guidance is helpful but lacks explicit exclusions or named alternatives.
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 within the localization domain: add_translation_memory_entry stores translations, get_brand_voice retrieves brand guidelines, get_languages and get_style_guides fetch configuration, get_translation_memory_stats provides metrics, search_translation_memory finds existing translations, translate handles single translations, and translate_batch processes multiple texts. There is no overlap in functionality, making tool selection unambiguous.
All tools follow a consistent verb_noun naming pattern (e.g., add_translation_memory_entry, get_brand_voice, search_translation_memory). The verbs are descriptive and appropriate for each action (add, get, search, translate), and snake_case is used uniformly throughout, creating a predictable and readable naming convention.
With 8 tools, the server is well-scoped for localization tasks, covering core operations like translation, memory management, and configuration retrieval. Each tool serves a specific and necessary function without redundancy, making the count appropriate for the domain and avoiding both bloat and insufficiency.
The tool set provides comprehensive coverage for AI-driven localization, including translation (single and batch), translation memory management (add, search, stats), and configuration access (brand voice, languages, style guides). A minor gap exists in the lack of update or delete operations for translation memory entries or style guides, but agents can still perform essential workflows effectively.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Your memory, everywhere AI goes. Build knowledge once, access it via MCP anywhere.
Connect MCP clients to 2,000+ AI models without managing provider API keys.
Let AI agents query data and act across all your business apps via MCP.
8 AI services via MCP: content, code, image, docs, data extraction, translation, SEO, email.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Nativ-Technologies/nativ-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
