Translation that never breaks structure: .srt timings, i18n key trees, PDF layout.
Check text for grammar, spelling and style issues in 30+ languages (self-hosted LanguageTool). Returns each issue with a suggested replacement — apply them to produce corrected text. Example — GET https://ainetcafe.com/t/check_grammar?text=Their+going+to+the+park
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The text to check (≤10000 chars). | |
| language | No | Language code like "en-US", "zh-CN"; default "auto". |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and idempotent behavior. The description adds useful context: it's a self-hosted LanguageTool, supports 30+ languages, and returns each issue with a suggested replacement. This goes beyond the annotations by describing the output format and the practical use of applying replacements.
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 compact—two sentences plus an example URL. The first sentence is a clear purpose statement, the second explains the output and usage, and the example adds practical context. It avoids fluff, though the URL adds a bit of length; overall it is well-structured and front-loaded.
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 relatively simple tool with a rich input schema (100% coverage) and an output schema, the description sufficiently covers what the tool does, its language support, and the nature of the returned issues. It explains the action of applying replacements, making the tool's purpose and usage complete enough for an agent to select and invoke it correctly.
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 surface-level meaning of both parameters is fully documented in the schema. The description's example only illustrates the 'text' parameter and does not add any semantics beyond what the schema already provides. It neither compensates nor detracts, so the baseline of 3 is appropriate.
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 verb 'Check' and the resource 'text for grammar, spelling and style issues', with a scope of 30+ languages. It also mentions the output (issues with suggested replacements), which helps distinguish it from sibling translation tools.
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 use by explaining that issues come with replacements and suggesting to apply them for corrected text. It does not explicitly name alternatives or state exclusions, but the unique purpose (grammar/style vs translation) is evident, meeting the 'clear context, no exclusions' level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the status or result of a job started by deep_research, translate_pdf, or make_slides. Poll every 15-30 seconds until status is "done" or "error". While work is pending, follow retry_after_seconds and next_action; when complete, prefer structured_result when present. Example — GET https://ainetcafe.com/t/check_job?job_id=
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | The job_id returned when the task was started. |
| Name | Required | Description |
|---|---|---|
| kind | No | |
| error | No | |
| job_id | Yes | |
| result | No | |
| status | Yes | |
| is_terminal | No | |
| next_action | No | |
| structured_result | No | |
| retry_after_seconds | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly and idempotent, but the description adds critical behavioral context: the expected statuses, polling interval, and how to handle pending vs. complete states. This goes well beyond the structured annotations and gives the agent a complete mental model of the tool's behavior.
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 compact (~50 words) and front-loaded with the primary purpose. Every sentence adds actionable information: purpose, polling guidance, response handling, and an example. No redundant or filler content.
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 (one parameter, output schema available), the description is remarkably complete. It covers purpose, how to poll, what to look for, how to respond to pending work, and how to handle results, leaving no ambiguity for an agent.
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 already documents job_id with a description, and coverage is 100%. The description adds value by specifying which tools produce the job_id and providing a concrete URL example, clarifying the origin and format of the parameter beyond the schema alone.
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 states a specific verb and resource: 'Get the status or result of a job started by deep_research, translate_pdf, or make_slides.' This clearly identifies the tool's function and distinguishes it from sibling tools like check_grammar and translation utilities, which serve different purposes.
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?
It explicitly explains when to use the tool (after starting a job with specific tools) and provides detailed polling instructions: 'Poll every 15-30 seconds until status is "done" or "error"'. It also guides follow-up actions with retry_after_seconds, next_action, and structured_result, making usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Translate an i18n JSON locale file, keeping the key structure identical and placeholders ({name}, {{count}}, %s, HTML tags) intact. Pass existing_json to translate only the keys that are missing from it — the incremental sync people usually hand-roll a script for.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Target language. | |
| url | No | Or a link to the source JSON. | |
| json | No | Source locale file content (JSON). | |
| existing_json | No | Existing target locale; only missing keys get translated. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond the annotations: it guarantees key structure and placeholder preservation, and explains the incremental behavior of existing_json. These are meaningful traits not visible from the annotations alone and do not contradict the readOnlyHint or idempotentHint.
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 two sentences, front-loaded with the core purpose, and includes a practical usage tip without filler. Every sentence earns its place.
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 rich schema, annotations, and output schema, the description covers the essential purpose, key behavioral guarantees, and the primary use case (incremental sync). No critical information is missing.
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 already describes all four parameters (100% coverage), so the baseline is 3. The description adds extra meaning by explaining the intent of existing_json ('only missing keys get translated') and by emphasizing placeholder handling, enriching the parameter context further.
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 uses a specific verb ('Translate') and clearly identifies the resource ('i18n JSON locale file'), while adding scope details about preserving key structure and placeholders. This distinguishes it from sibling tools like translate_text or translate_pdf.
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?
It gives clear context for when to use this tool—translating JSON locale files—and specifically explains the existing_json parameter for incremental sync, calling out a common manual alternative. It doesn't explicitly name sibling tools or state when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Translate a PDF from a URL while preserving the original layout — formulas, figures and two-column academic typesetting stay intact, unlike ordinary translators that flatten the document. Returns a job_id; poll check_job for the download links (translated-only and bilingual side-by-side). Typically 20-60 seconds for a few pages. Powered by PDFMathTranslate (36k stars) hosted at AI NetCafé. Example — tools/call translate_pdf {"url":"","target":"zh"} → poll check_job
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Direct URL to the PDF (e.g. an arXiv PDF link). | |
| pages | No | How much to translate. first = 1 page, first5 = first 5 pages (default), all = whole document (slow and expensive). | |
| lang_to | No | Target language, e.g. "Simplified Chinese", "Japanese". Default Simplified Chinese. |
| Name | Required | Description |
|---|---|---|
| job_id | Yes | |
| status | Yes | |
| poll_interval_seconds | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite all annotations being false (which carry little meaning), the description discloses key behavioral traits: it is asynchronous (returns a job_id to poll), provides runtime expectations ('Typically 20-60 seconds'), mentions the underlying engine (PDFMathTranslate) and host (AI NetCafé), and notes the output includes translated-only and bilingual side-by-side downloads. This goes well beyond the annotations, though it omits failure modes or data retention 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 concise and well-structured: purpose/benefit (sentence 1), output and next step (sentence 2), performance (sentence 3), and provider/example (sentence 4). Every sentence adds distinct value, and the information is front-loaded with the primary purpose first.
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 that an output schema exists and the input schema is complete, the description covers the essential runtime workflow: it tells the agent to return a job_id and poll check_job for downloads, describes the two output types, and gives a realistic time estimate. The addition of an example and the tool's provenance make it sufficiently complete for an agent to invoke and follow up correctly.
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 already documents all three parameters with 100% coverage, so the baseline is 3. However, the description contains a concrete example that uses 'target' instead of the schema's 'lang_to' ('"target":"zh"'), which directly conflicts with the parameter naming and could mislead an agent. This active misinformation drops the score below baseline.
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 a PDF from a URL while preserving the original layout' with specific detail about formulas, figures, and two-column academic typesetting. It distinguishes itself from 'ordinary translators that flatten the document' and from sibling tools like translate_text and translate_srt by focusing on PDFs and layout preservation.
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 explains when this tool is appropriate (when preserving layout matters, e.g., academic papers) and how to use it: returns a job_id and instructs to poll check_job. It also sets expectations with the example and typical runtime. However, it does not explicitly list exclusions like 'use translate_text for plain text' or 'use translate_srt for subtitles', so it stops short of full alternatives guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Translate an .srt subtitle file into another language while keeping every timestamp and cue number byte-identical. Cues are anchored by index and refilled in code, so the timeline cannot drift — the usual failure mode when you hand a whole .srt to a model.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Target language, e.g. "English", "日本語". | |
| srt | No | The .srt file content. | |
| url | No | Or a link to the .srt file. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly, idempotent, non-destructive), the description reveals the internal anchoring and refilling mechanism, guaranteeing no timeline drift. This is significant behavioral context that explains how the tool achieves its promise and what to expect.
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?
Two sentences, front-loaded with the main action and key guarantee. The second sentence adds valuable context without being verbose. Every word earns its place.
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 subtitle translation tool with an output schema and good annotations, the description is complete. It explains the core feature, the technical approach, and the benefit over naive translation, leaving no critical gaps.
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 schema already covers all three parameters with descriptions, so the baseline is 3. The description does not add further semantic detail about the parameters themselves, just the overall file type. This aligns with the schema coverage of 100%.
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 verb 'Translate' and resource '.srt subtitle file', with the specific constraint of keeping timestamps and cue numbers byte-identical. This distinguishes it from sibling tools like translate_text and translate_pdf, which handle different input types.
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 context is clear: use this tool when you have an .srt file and need to preserve the timeline. It also warns against the common failure mode of handing a whole .srt to a model, which implies when this tool is preferable. However, it doesn't explicitly name alternatives or state exclusions, so a 4 is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Translate text between languages using a self-hosted LibreTranslate engine (fully offline, no big-tech API). For whole PDFs with layout preserved, use translate_pdf instead. Example — GET https://ainetcafe.com/t/translate_text?text=hello+world&to=zh
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Text to translate (≤5000 chars). | |
| source | No | Source language code; default "auto". | |
| target | Yes | Target language code, e.g. "zh", "en", "ja". |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds meaningful behavioral context by stating 'fully offline, no big-tech API', which conveys data-handling traits. The example shows a GET request, but its parameter name is inconsistent with the schema (to vs target), slightly undermining trust, though this is more of a parameter issue.
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 with two sentences and an example, but the example is inaccurate (wrong parameter name), so not every sentence earns its place. It is still appropriately front-loaded with purpose and usage guidance, but the factual error prevents a perfect score.
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?
An output schema exists, so return values are not needed in the description. The description includes the purpose, an alternative, and an example, but the example's error creates a gap in practical usability. It also lacks information about rate limits or error handling, but these are not required for simple translation. The tool is relatively simple, so overall completeness is adequate but flawed by the example.
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?
Although the input schema covers 100% of parameters with descriptions, the example in the description uses 'to' instead of the schema's 'target' parameter name. This is a direct contradiction with the schema and would mislead an agent into using an invalid parameter. The description actively undermines parameter understanding, so despite high schema coverage, the score is a 1.
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 it translates text between languages using a self-hosted LibreTranslate engine, and explicitly mentions 'fully offline, no big-tech API' to distinguish it from other translation tools. It also points to translate_pdf for whole-PDF translation, which differentiates it from a sibling tool. This is a specific verb+resource+scope with clear differentiation.
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 gives a clear usage context: translate text online via a self-hosted engine, and explicitly names an alternative (translate_pdf) for PDFs with layout preserved. It doesn't discuss when not to use this tool for other formats like SRT or JSON, but the provided alternative and the offline context give sufficient guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Describe a task in plain language (any language) and get back exactly which tools on this server do it, with ready-to-run example calls — instead of reading the whole catalogue and guessing. Also returns multi-step recipes when a task needs several tools chained (invoices to a ledger, a bank statement reconciled, a messy CSV turned into a deliverable). Deterministic and free: it calls no model, costs nothing, and never runs out of quota. Call this FIRST when you are not sure what this server offers.
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | What you are trying to do, e.g. "reconcile a bank statement against my books" or "把一堆发票整理成能入账的表格" |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false, but the description adds meaningful behavioral context: 'Deterministic and free: it calls no model, costs nothing, and never runs out of quota.' This discloses resource usage and invocation behavior beyond the annotations. It also mentions it returns multi-step recipes, which is an important behavioral trait.
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, each serving a distinct purpose: the primary function and benefit, the advanced recipe capability, and the cost/determinism plus usage recommendation. Every sentence contributes new, relevant information without redundancy, making it well-structured and appropriately sized.
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 meta-purpose, the description covers all necessary angles: what it does, when to call it, behavioral guarantees (deterministic/free), and what it returns (tool recommendations and multi-step recipes). The presence of an output schema covers the return format, so nothing critical is missing.
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 schema description covers 100% of the single 'task' parameter, but the description enhances it by adding 'plain language (any language)' and giving concrete examples such as 'reconcile a bank statement against my books' or '把一堆发票整理成能入账的表格.' This adds semantic clarity beyond the schema's generic 'What you are trying to do.'
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 function: 'Describe a task in plain language... and get back exactly which tools on this server do it, with ready-to-run example calls.' It uses a specific verb ('get back') and names the resource ('tools on this server'), and it is immediately distinguishable from sibling tools like translate_text or check_grammar, which perform specific tasks rather than recommending tools.
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 advises when to use this tool: 'Call this FIRST when you are not sure what this server offers.' It also frames it as an alternative to 'reading the whole catalogue and guessing,' giving clear context for using it over the sibling tools. This is direct, unambiguous guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user or an account that owns the GitHub organization, then choose Claim with GitHub.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Accurate, brand-controlled translation for text, code, images, and documents with terminology.
Translation QA: automated checks, AI evaluation, linguistic review, and visual in-context testing.
Audit localized tutorials and safely maintain project metadata and pronunciation rules.
AI localization for agents: translation, TMS sync, translation memories, glossaries, post-editing.
Add one secure layer between your agents and this server.
Each tool targets a distinct resource or action: plain text, PDF, SRT, JSON, grammar checking, and job polling. There is no meaningful overlap, and the descriptions explicitly call out when to use one over another (e.g., translate_text vs translate_pdf).
All tools follow a clear verb_noun pattern in lowercase snake_case: check_grammar, check_job, translate_i18n_json, translate_pdf, translate_srt, translate_text. The two verbs (check_ and translate_) correspond to their functional groups, making the naming predictable and easy to navigate.
Six tools is a well-scoped count for a translation-focused server. Each tool has a distinct purpose and earns its place; the set is neither bloated nor too thin.
The surface covers the core translation formats (text, PDF, subtitles, i18n JSON) plus async job status and grammar checking. Minor gaps exist, such as support for other document formats (e.g., DOCX) or a language-list endpoint, but these are not essential to the apparent purpose.
