Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations mark it as not read-only, and the description is consistent by disclosing that it may download a result. However, it does not explain what happens if the job is still running, failed, or how polling should be handled.

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 short sentences with no wasted text, and the primary action is 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?

It covers the basic purpose and timing for a job-checking tool, but without an output schema it does not describe return values or behavior when the job is incomplete or fails. The schema documents the parameters, but the description leaves some operational 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?

Schema description coverage is 100%, so all three parameters are already documented in the schema. The description mentions looking up by id and downloading a result but adds no extra detail about output_path or document_path 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 states a specific verb and resource: look up a job by id and download its result if finished. It is clear and actionable, though it does not explicitly distinguish this job-checking tool from any sibling tool.

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 a clear usage condition: use this after a tool returned before the job was done. It does not state when not to use it or describe alternatives, but the triggering scenario is explicit.

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?

Adds substantial context beyond annotations: output is saved next to the source, a path is returned, and the operation burns credits at 20/1,000 words with a 10 minimum. Minor gap: it implies a synchronous path return while the wait_seconds parameter suggests a job-id/async mode that the description never explains.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences: what it does, what it produces, then the cost warning. The most decision-critical information (credit cost and consent requirement) is placed where it will be read, with no filler.

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 5-parameter mutation tool with no output schema, the description covers purpose, output location, and cost—the things an agent most needs. The async job-id flow implied by wait_seconds and the check_job sibling is left to the schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so parameters are already documented. The description only reinforces max_words and the default output location, adding no syntax, format, or constraint detail beyond the schema. Baseline 3 applies.

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?

States a specific verb and resource ('Shorten a .docx to a target word count') plus the invariants it preserves (meaning, structure, citations). This is clearly distinct from siblings like humanize_document, translate_document, and fix_citations.

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?

Gives an explicit operational precondition ('say so and get agreement first') for the credit cost, which is a real gating instruction. It does not explicitly name alternatives or when-not-to-use, but the credit caveat is a strong usage signal.

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?

Goes well past the annotations: it discloses that only citations and the reference list are touched, that a new file is written beside the source, that the path is returned, and a concrete credit price with a 10-credit floor. The agreement-before-charging instruction is exactly the kind of behavioral context annotations cannot carry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, each carrying distinct information: what changes, what is produced, and what it costs. The cost warning is capitalized and front-loaded enough to catch the eye before invocation.

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?

It covers scope, output location and pricing, and the missing output schema is offset by the stated return value. The gap is the async surface: wait_seconds and a job id are never mentioned, so an agent is not told that it may need to poll via check_job.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so style, output_path, instructions and wait_seconds are already documented in the schema and the description correctly does not repeat them. It adds only the notion of a single 'target style' and the beside-source default, both of which the schema already states, so this is baseline territory.

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?

States a specific verb and resource ('Rewrite a .docx's in-text citations and reference list') plus a precise scope constraint ('leaving the body text alone'). That scope line alone distinguishes it from any formatting-adjacent sibling and tells an agent exactly what changes and what does not.

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?

Gives an explicit precondition for invocation ('say so and get agreement first') tied to the credit cost, which is real usage guidance rather than none. It stops short of naming when-not-to-use-it or pointing at siblings like humanize_document, but the domain is different enough that little inference is required.

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?

Goes well past the annotations by disclosing enforcement rules the agent cannot infer: one free continuation per job, a per-day cap, a >=90% report match requirement, a >=20% AI threshold, and a ~7-day result retention window. It also specifies failure behavior ('returns a clear reason - relay it and stop'), which is the most operationally important trait here.

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?

Front-loads the free-continuation purpose, then constraints, then the failure directive, then the parameter hint — a sensible priority order. Every sentence carries a distinct rule; nothing is redundant with the schema or annotations.

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 6-parameter, no-output-schema tool, the description covers preconditions, cost, limits, failure handling, and where job_id comes from. There is no output schema, and the description still tells the agent what to expect back (a job id or a clear refusal reason).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds genuine meaning: job_id must come from a prior humanize_document or check_job call, and report_path must be a report of that job's own result. It leaves segments, output_path, and wait_seconds to the schema, which is reasonable since those are already documented.

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?

States a specific verb and resource ('Continue a finished humanize job') plus a distinctive constraint ('for FREE') that separates it from the sibling humanize_document. It also names the input artifact (a fresh detection report) and its effect (only still-flagged passages are rewritten), so an agent can identify the tool without opening the schema.

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?

Explicitly scopes usage: only for an already-finished humanize job, requires a report of THAT job's result, and only runs once per job. It also closes off wrong behavior directly ('do not retry or silently fall back to a paid job'), which is precisely the routing decision an agent could get wrong.

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?

readOnlyHint=true already covers the safety profile, so the description's value-add is the cost model: per-1,000-word rates for humanize/citation/condense/translate plus a 10-credit per-job minimum. That is genuinely useful planning context not present in any structured field. It stops short of describing the response shape or whether the balance is account- or workspace-scoped.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences: identity first, pricing second, usage recommendation last. Every clause carries information an agent would actually use, with no restatement of the title or name.

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 zero-parameter read with no output schema, the description covers what it does, what things cost, and when to call it. The only gap is what the returned balance actually looks like (remaining vs. total, units), which an agent must infer.

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 takes zero parameters, so the baseline is 4; there is nothing for the description to disambiguate. The added per-unit cost detail is helpful orientation rather than parameter semantics.

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 opening sentence states exactly what is returned — the account's credit count — which is unambiguous against siblings like check_job or read_detection_report. The verb is implicit (phrased as a question) rather than an explicit 'retrieve', which keeps it just short of a 5.

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?

'Worth checking before a large document' gives a concrete trigger condition, and the cost table lets the agent decide whether a job is affordable. No other balance-related sibling exists, so no exclusions are needed, but it never states what to do if the balance is insufficient.

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 only say destructiveHint=false and readOnlyHint=false; the description adds the substantive behavior: 100 credits per 1,000 words (10 minimum) with a requirement to disclose and get consent, the result saved beside the source with a returned path, and the iterative second-pass semantics. That is far beyond what the annotations convey.

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 core action and preserved invariants are front-loaded, and the credit warning is capitalized and placed where it will be read. It is longer than typical but each sentence carries operational information, with only mild redundancy between the description and the schema on word-limit caveats.

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 paid, iterative mutation tool with no output schema, the description covers cost and consent, result location and return value, the report-scoped mode, and the rerun workflow. An agent has everything needed to call it and set expectations 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 coverage is 100%, so baseline is 3, but the description adds meaning the schema doesn't: 'balanced' remains correct for a second pass, and report_path scopes rewriting to flagged passages. It doesn't add syntax detail for output_path, instructions, or wait_seconds, keeping it at 4.

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 opening sentence names a specific verb (rewrite), the exact resource types (.docx/.pptx), the goal (lower AI-detector scores) and the invariants preserved (meaning, citations, tables, layout). An agent can distinguish this from condense_document or translate_document without opening the schema.

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 explicit when-to-use detail: optionally pass a Turnitin/iThenticate report to scope rewriting, and rerun with a fresh report if the result is still flagged. It also mandates getting user agreement before spending credits. It stops short of naming alternatives like free_rehumanize for the free path, so not a full 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?

Annotations already declare readOnlyHint=true, so the safety profile is covered; the description adds genuine context beyond that — the operation is free, does not start a job, and is the input to humanize_document. It stops short of describing failure modes for malformed or non-AI-writing PDFs, keeping it below a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, front-loaded with the verb, resource, and payload, then cost/side-effect, then the handoff to the sibling tool. No filler and nothing an agent needs is buried.

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 no output schema, the description carries the return-value burden and does so by naming the overall AI percentage and flagged passages. The one gap is error behavior for unreadable or unsupported PDFs, but for a simple read-only parse tool this is close to 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?

Schema description coverage is 100%, so all three parameters (including the enum and the default-false include_segments) are already documented in the schema. The description mentions the return of flagged passages but adds no format or syntax detail beyond the schema, so baseline 3 applies.

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?

States a specific verb and resource ('Read a Turnitin or iThenticate AI Writing report PDF') and explicitly lists the return payload: overall AI percentage and flagged passages. This is clearly distinguishable from siblings like humanize_document or check_job.

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?

Explicitly notes 'Free - reads the file without starting a job,' which tells the agent no job/credit path is involved, and it names the downstream alternative: pass the same report to humanize_document to rewrite only flagged content. Both when-to-use and what-to-do-next are stated.

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 only declare it is a non-read-only, non-destructive write; the description adds the real behavioral facts an agent needs: credit cost and rate (10 per 1,000 words, 10 minimum), that output is saved beside the source, and that a path is returned. It omits that the call may return a job id requiring the check_job sibling, which is the one significant undisclosed 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?

Three tightly packed sentences led by the core action, then scope, then output, then the cost warning in caps. Every sentence carries distinct information and nothing is repeated from the schema.

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 paid mutation tool it covers the essentials: what is preserved, accepted formats, where output lands, what is returned, and the cost/consent requirement. The missing piece is the asynchronous job-id path (wait_seconds default 55, then check_job), which an agent needs to complete the workflow.

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 all five parameters are already documented in the schema; the description only reinforces the default output location ('saves the result next to the source'). It adds no language-format guidance or detail on wait_seconds/job behavior 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?

States a specific verb+resource (translate a document) plus the distinguishing property that sets it apart from siblings like condense_document or humanize_document: layout/tables/images/formulas are preserved, and a file is written. The supported format list further pins down exactly what it operates on.

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?

Gives a concrete, actionable usage rule: it costs credits, so the agent must say so and get agreement first. It does not name a sibling alternative or state when-not to use it (e.g. condense vs translate), so it falls short of the explicit routing seen in top-tier definitions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.