Translation that never breaks structure: .srt timings, i18n key trees, PDF layout.
Scored across 7 tools
Each tool targets a clearly distinct task: grammar checking, text translation, PDF translation, subtitle translation, JSON locale translation, job status polling, and capability discovery. There is no meaningful overlap between tool purposes, and even translate_text carefully defers to translate_pdf for whole documents.
Tools mostly follow a clean verb_object snake_case pattern such as translate_text, translate_pdf, and check_job. The one outlier is what_can_you_do, which is a question-style helper rather than an action_verb_object name, but it is still lowercase snake_case and self-explanatory.
Seven tools is well-scoped for a translation-focused server. Each tool covers a meaningful and distinct format or workflow without padding, and the inclusion of check_job and what_can_you_do supports the async and discovery needs of the set.
The tool surface covers the main translation workflows: plain text, layout-preserving PDFs, subtitle files, and i18n JSON files, plus grammar checking and async job retrieval. Minor gaps like DOCX/PPTX translation or language detection exist, but they are not core to the stated purpose and can be worked around.
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 readOnlyHint, idempotentHint, and non-destructive behavior. The description adds critical behavioral context: the polling interval, the terminal statuses, the handling of intermediate responses (retry_after_seconds, next_action), and the preference for structured_result. It also includes a concrete GET URL example, fully disclosing the interaction pattern.
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 information-dense but not verbose, delivering purpose, polling guidance, response handling, and an example in three sentences. Each sentence earns its place, and the example is clearly separated for easy scanning.
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?
With an output schema present, return values are already specified, so the description correctly focuses on the asynchronous polling protocol. It covers when to call, how to poll, what to do while pending, what to do on completion, and the exact endpoint format, making it fully self-contained for correct invocation.
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 fully documents job_id (100% coverage), so the baseline is 3. The description enhances this by specifying that the job_id comes from deep_research, translate_pdf, or make_slides, and by showing its placement in the URL example, which adds context beyond the schema's generic 'returned when the task was started'.
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 identifies the verb ('Get'), the resource ('the status or result of a job'), and the originating tools (deep_research, translate_pdf, make_slides). This differentiates it from sibling creation tools like make_badge or render_diagram, which are all about generating artifacts rather than checking job status.
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 explicit usage guidance: poll every 15-30 seconds until status is 'done' or 'error', follow retry_after_seconds and next_action while pending, and prefer structured_result when complete. It also indicates the tool is for jobs started by specific tools, which serves as both an inclusion and exclusion criterion.
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?
The description discloses asynchronous behavior (returns job_id, poll check_job), expected latency (20-60 seconds), output formats (translated-only and bilingual), and underlying technology (PDFMathTranslate). This adds significant context beyond the sparse annotations.
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, front-loaded with purpose, and includes a concrete example. However, the example contains an incorrect parameter name, which slightly undermines the efficiency and reliability of the information.
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?
With a full input schema and an output schema present, the description appropriately explains the async workflow, polling, and output types. It does not need to detail return values. The minor error in the example does not compromise overall completeness but detracts slightly.
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?
While schema coverage is 100% and the schema already documents all parameters, the description's example uses 'target' instead of the actual parameter 'lang_to', which is misleading. This introduces an ambiguity that could cause incorrect tool invocation.
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: 'Translate a PDF from a URL while preserving the original layout' and highlights unique features (formulas, figures, two-column typesetting) that distinguish it from ordinary translators and sibling tools like pdf_to_markdown. The example flow reinforces the purpose.
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 on when to use the tool (for layout-preserving PDF translation from a URL) and contrasts it with 'ordinary translators that flatten the document'. However, it does not explicitly specify when not to use it or name alternative tools among the siblings.
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 declare readOnlyHint, idempotentHint, and destructiveHint. The description adds valuable behavioral traits not visible in annotations: deterministic, calls no model, costs nothing, and never runs out of quota. No contradiction with annotations.
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?
Four dense sentences, front-loaded with the core purpose in the first sentence and supported by recipes, cost/quota guarantees, and when-to-use guidance. Every sentence earns its place; no filler or repetition.
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 simple context (single required string parameter, rich annotations, and an output schema), the description is complete. It covers the tool's behavior, return value highlights, performance/cost characteristics, and usage context without leaving important 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 input schema already describes the 'task' parameter with examples, and schema coverage is 100%. The description adds the nuance 'plain language (any language)' and emphasizes that example calls are generated, providing modest additional meaning beyond the 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 a specific verb+resource: describe a task and get back exactly which tools on the server do it, with ready-to-run example calls. It explicitly distinguishes itself from sibling tools by positioning itself as the meta-guide that prevents 'reading the whole catalogue and guessing.'
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?
Provides explicit when-to-use guidance: 'Call this FIRST when you are not sure what this server offers.' It also clarifies the intended use case (plain-language task discovery) and contrasts with the alternative of scanning the catalogue manually, which is sufficient for a meta-tool.
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.
what_can_you_docheck_grammarcheck_jobtranslate_i18n_jsontranslate_pdftranslate_srttranslate_textAccurate, brand-controlled translation for text, code, images, and documents with terminology.
Translate PDF, Word, Excel, Markdown, image and video files with Belindoc, and rewrite subtitles.
Transcribe, subtitle and dub videos into 100+ languages, and translate text.
Translation QA: automated checks, AI evaluation, linguistic review, and visual in-context testing.
Add one secure layer between your agents and this server.
