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

No annotations are present, so the description bears full responsibility for behavioral disclosure. It mentions downloading if finished, but does not describe behavior when the job is not finished (e.g., polling, error, status return), whether it blocks, or side effects like writing to the file system without clarity.

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 primary action, and contains no wasted words. It is concise and easy to parse.

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 lack of annotations and output schema, the description provides the core purpose and usage but omits important behavioral details such as non-finished job behavior, error handling, and whether output_path is mandatory for downloads. It is adequate but has clear gaps for an async job tool.

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

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

Schema coverage is 100% and all parameters have descriptions, so the baseline is 3. The description adds context about downloading results and usage timing but does not add significant semantic detail beyond what the schema already provides for each parameter.

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 looks up a job by ID and downloads the result if finished, which is specific and distinguishes it from the sibling tools that operate on documents. The verb 'look up' and resource 'job by id' are explicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear usage context: 'Use this after a tool returned before the job was done.' It does not explicitly mention alternatives or when not to use it, but the given guidance is sufficient for typical async job polling scenarios.

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?

With no annotations, the description carries the full burden. It discloses cost structure (100 per 1,000 words, 10 minimum), the need for user agreement, output location ('Saves the result next to the source'), and return value ('returns its path'). This is meaningful behavioral context beyond the schema.

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 that are direct and information-dense: function, output behavior, and cost/consent. No filler words or redundant restatement of the title. 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?

The description claims 'returns its path', but the schema includes a wait_seconds parameter that 'return[s] a job id', implying asynchronous behavior. The description does not explain when a path vs. a job id is returned, nor does it mention the sibling check_job tool for tracking. This is a significant gap for effective tool 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?

Schema coverage is 100%, so baseline is 3. The description adds context around output_path (saves next to source) and max_words (target word count), but it does not elaborate on individual parameter syntax or edge cases. It meets the baseline but does not significantly exceed it.

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: 'Shorten a .docx to a target word count', naming the verb (Shorten), resource (.docx), and key constraint (target word count). This distinguishes it from siblings like humanize_document or translate_document.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use it (to condense a document) and includes a critical usage guideline: 'COSTS CREDITS... say so and get agreement first.' It does not explicitly mention alternatives, but the context is clear and it provides a behavioral requirement.

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?

With no annotations provided, the description carries the full burden. It discloses meaningful behaviors: it modifies only citations (leaves body text alone), saves the result next to the source (non-destructive), returns the path, and costs credits at a specific rate. However, it does not disclose the asynchronous job-id behavior implied by the wait_seconds schema parameter, which is a minor transparency gap.

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

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

The description is three sentences, each serving a distinct purpose: the main action, the output behavior, and the cost/consent requirement. It is front-loaded with the core functionality and has no redundant phrasing.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the core action, output location, return path, and cost, but it omits important context about the asynchronous nature of the tool (job id vs. path) and potential error conditions, which are not captured in an output schema. Given the existence of a parameter like wait_seconds and a sibling check_job, the description could be clearer about the execution model to avoid agent misinterpretation.

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 documents all 5 parameters with 100% coverage, including allowed styles and the default behavior for output_path. The description adds no new parameter-specific details; it only restates the style rewrite behavior and output location, which are already in the schema. Therefore, the description provides marginal added value 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 uses the specific verb 'Rewrite' to target '.docx's in-text citations and reference list' with an outcome 'into one target style'. It explicitly says 'leaving the body text alone', which scopes the operation precisely. This clearly distinguishes it from sibling tools like humanize_document or translate_document, which handle broader text transformations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage by stating the exact function: rewriting citations into a target style. It doesn't explicitly name alternatives or exclusions, but the focus on citations and reference lists provides clear context for when to select this tool over siblings. It also includes an operational guideline about securing user agreement due to credit costs.

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?

With no annotations provided, the description fully discloses server-side constraints: one free continuation per job, per-day cap, required >=90% match, >=20% AI in the report, and that results are kept ~7 days. It also explains error handling and prohibits retries/fallback, making behavior highly transparent.

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 moderately lengthy but every sentence contributes essential information (free nature, limits, error behavior, no-fallback rule). It is front-loaded with the core purpose, making it easy to parse despite the detail.

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 6 parameters, no annotations, and no output schema, the description covers the tool's core behavior, constraints, and error handling well. It omits explicit return-value information, but since no output schema exists, this is not strictly required. It is adequately complete for the tool's complexity.

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% for all six parameters, so the baseline is 3. The description adds minimal semantic value beyond the schema; it mentions passing job_id from a prior humanize_document/check_job, but the schema already states this. Optional parameters are not elaborated in the description, though the schema covers them.

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 explicitly states the tool continues a finished humanize job for free, rewrites only still-flagged passages, and is distinct from the paid sibling humanize_document. It also includes the directive not to fall back to a paid job, which further distinguishes it from alternatives.

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 clear context: use after a finished humanize job with a fresh detection report. It includes when-not-to (do not retry or silently fall back to a paid job) but does not explicitly name alternative tools like check_job for status checks, so it stops short of 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?

With no annotations provided, the description carries the burden of disclosing behavior. 'How many credits the account has' implies a read-only query with no side effects. It also adds useful context about the credit system (charges per 1,000 words and 10-credit minimum), which helps the agent judge when to check. It does not mention return format, but for a simple balance check this is acceptable.

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 and front-loaded. The first sentence states exactly what the tool does. The second sentence provides relevant cost information and a usage tip, earning its place. No wasted words.

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?

This is a simple tool with no parameters and no output schema. The description fully covers its purpose, provides usage guidance, and gives background on credit consumption. The sibling tools are all credit-consuming operations, so the 'before a large document' tip is sufficient contextual guidance. Nothing important 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 tool has zero parameters, so schema coverage is 100% by default. The baseline for 0 params is 4. The description adds value by explaining the credit cost model, which gives context for interpreting the balance, even though it is not parameter-specific.

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: 'How many credits the account has.' This is a specific read operation with a clear resource (credit balance). It is distinct from all sibling tools, which perform document operations or job checks, so there is no ambiguity.

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 usage context: 'Worth checking before a large document.' This signals when to use the tool relative to the credit-consuming sibling tools. It does not explicitly name alternatives or exclusions, but the context is clear and actionable.

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?

With no annotations, the description fully carries the burden and does so exceptionally. It discloses cost (100 credits per 1000 words), the iterative behavior with re-runs, that only flagged passages are touched when a report is provided, output saving next to the source, and the returned path. This is far beyond the bare minimum and gives agents clear expectations.

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 about four sentences long, starts with the core purpose, and every sentence adds a distinct piece of information: main functionality, optional report usage, iterative re-run guidance, and cost warning. There is no redundant or filler text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite 9 parameters and no output schema, the description covers all essential context: main use case, optional report integration, re-run strategy, file type constraints, output path behavior, and cost. Combined with the fully described schema, this gives an agent everything needed to invoke the tool 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 parameters are well-documented, but the description adds contextual meaning beyond schema by explaining the strategy choice (balanced vs aggressive) for first and second passes, the purpose of report_path, and the default output behavior. It also ties the re-run guidance to the strategy and report parameters, helping agents make informed choices.

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 rewrites .docx or .pptx files to read as human-written and lower AI detection scores, while preserving meaning, citations, tables, and layout. This specific verb+resource scope distinguishes it from sibling tools like condense_document or translate_document.

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 explains when to use the tool, including the option to pass a Turnitin/iThenticate report to rewrite only flagged passages, and advises re-running with balanced strategy if a fresh report still flags results. It does not explicitly contrast with alternatives, but the guidance implies the primary use case and iterative workflow.

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?

No annotations are provided, so the description carries the burden. It discloses that the operation is free, does not start a job, and returns the AI percentage and flagged passages – key behavioral traits for a read-only tool. It could add more about error handling or output format, but the core transparency is present.

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 purpose and outputs. The second sentence adds cost and chaining guidance. No wasted words.

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 read tool with 3 parameters and no output schema, the description explains the return values (AI percentage and flagged passages), the cost/free behavior, and connects to humanize_document. This is sufficient for an agent to decide and invoke.

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 all three parameters already have descriptions. The tool description does not add further parameter-level meaning beyond mentioning flagged passages (which relates to include_segments). Baseline 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?

Description states 'Read a Turnitin or iThenticate AI Writing report PDF: returns the overall AI percentage and the flagged passages' – a specific verb with a clear resource and output. It also distinguishes itself from humanize_document by referencing it as a separate rewrite 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?

Explicitly says 'Free - reads the file without starting a job', establishing a clear when-to-use justification. It also directs the user to 'Pass the same report to humanize_document to rewrite only what was flagged', an explicit alternative for the next step.

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 discloses useful behaviors like saving next to the source, returning the path, and credit costs. However, it contradicts the input schema's wait_seconds parameter, which mentions returning a job ID. This creates ambiguity about whether the tool runs synchronously or asynchronously, a critical 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?

Three sentences, each earning its place: purpose, supported formats, output/cost behavior. Front-loaded, scannable, and free of 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?

With no output schema and no annotations, the description must clarify return values and job behavior. The 'returns its path' statement conflicts with the job-id mention in wait_seconds, and the existence of sibling check_job implies asynchronous processing. Missing details on failure modes or polling make it incomplete.

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 description adds marginal value. It does add supported-formats context beyond the schema, but fails to reconcile the wait_seconds behavior described in the schema, leaving potential confusion.

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 translates a document into another language while preserving layout, tables, images, and formulas. It also lists supported file formats, which distinctly separates it from sibling tools like condense_document or humanize_document.

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 context by listing accepted formats and requires credit-cost agreement before use, implying when it should be used for document translation. However, it never explicitly mentions alternatives or when not to use this tool, leaving the choice versus sibling tools implicit.

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