netcafe-translate

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.

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.

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.

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.

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.

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.