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

Annotations are all false (not read-only, not idempotent, not destructive), so the description carries the full burden. It discloses that every call creates a new render that counts units, that the Free plan cannot convert, and that the document is 'not kept.' It also specifies the output (render with status and download_url). 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?

The description is compact but information-dense, front-loading the core purpose and then covering alternatives, inputs, costs, and storage in a logical sequence. Every sentence earns its place; no fluff 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 8 parameters, no output schema, and complex alternatives, the description covers the essential operational context: what inputs are allowed, what is returned, cost implications, and storage behavior. It lacks explicit detail on error conditions or status code meanings, but these are minor for a conversion tool with a sibling 'get_render' for retrieval.

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 baseline is 3. The description adds valuable semantic constraints not in the schema: exactly one source must be provided, and render_id must be from a Word/PowerPoint template. This goes beyond simple parameter names and justifies a 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 description states a specific verb ('converts'), lists supported formats and size limit, and clearly differentiates from the sibling 'render' by saying 'To make a document from a template and data, use render instead.' The purpose is unambiguous and distinguishes the tool from all siblings.

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 tells when to use this tool vs. render, and provides a critical constraint: 'Pass exactly one source' among render_id, path, or file_base64. It also clarifies plan eligibility and unit counting, which informs decision-making. This is complete usage 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?

Annotations already declare readOnlyHint=true and destructiveHint=false. The description goes beyond these by adding that the call is free, that an unknown id returns an error, and that download URLs expire. This gives the agent useful operational context beyond the structured 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 front-loaded with the core purpose, then usage guidance, then behavioral notes. Every sentence earns its place and the whole thing remains compact despite covering return fields, polling, expiry, alternatives, and error behavior.

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?

Since there is no output schema, the description carries the burden of explaining the return value, and it does so thoroughly by listing status values and response fields. It also covers why the tool exists, when alternatives are preferable, cost, and error behavior, which is complete for a simple read-only lookup 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%, so the id parameter is already documented. The description adds value by clarifying that the id comes from a render or convert_to_pdf call and by exposing the unknown-id error behavior, which the schema does not state.

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 opens with a specific verb and resource: 'Returns the current state of a render', and enumerates the exact fields returned (status, download_url, expires_at, page_count, units, error). It distinguishes itself from siblings by noting render and convert_to_pdf already return this information for a just-created render.

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 states when to use this tool: to follow a render started with wait false, or to refresh an expired download link. It also names alternatives and their relationship: render and convert_to_pdf already return the same data for the render they just made, so this tool is for later or renewed access.

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 and destructiveHint, but the description adds valuable context: it is free, returns an error for unknown slugs, and explains that inferred schemas are a guide not a contract. This goes beyond the structured metadata and helps the agent anticipate edge cases.

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, front-loads the core purpose, and every sentence adds meaningful information. It covers return content, workflow, caveats, and error behavior without redundancy or fluff.

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-only tool with one parameter and no output schema, the description fully covers what an agent needs: what it returns, which version is used, when to call it, the inference caveat, and error behavior. Nothing essential 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?

Schema coverage is 100% and the parameter description in the schema is sufficient ('Slug (e.g. invoice) or tpl_ id, as list_templates returns them'). The description adds no additional parameter-level detail, so it neither enhances nor detracts from the schema. 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?

The description clearly states the tool returns the JSON Schema and sample data for a template's `data` object, specifying the resource and action. It distinguishes itself from siblings by placing it in the workflow (after list_templates, before render/validate_template) and noting ad-hoc html lacks a stored schema, making it unambiguous which tool to pick.

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 instructs when to call it ('after list_templates and before render or validate_template') and provides a negative case (ad-hoc html has no stored schema). It also explains the fallback inference behavior, giving the agent clear decision criteria without needing to infer usage.

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 mark this as read-only and non-destructive, but the description adds meaningful behavior beyond that: ordering by most recent change, exclusion of archived templates, an empty list on no match, and the null published_version meaning render cannot use the template. The statement 'Read-only and free' reinforces the annotation without contradicting it.

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 dense but every sentence earns its place: it covers output fields, ordering, usage guidance, edge cases, and safety in a compact paragraph. Key guidance is front-loaded and no filler is present.

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 sufficiently documents what the response contains, the available filter fields, the behavior with archived templates and empty results, and the special meaning of null published_version. It also provides enough context for an agent to decide when to call this tool versus its siblings.

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% and each parameter already has a clear description with examples and enum details. The tool description does not add significant parameter-level semantics beyond what the schema provides, so the baseline score 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 states a specific verb and resource: 'Lists the templates of the workspace the API key belongs to', and specifies the returned fields and ordering. It also differentiates itself from sibling tools by explaining that it provides the slug used by get_template_schema, validate_template, and render.

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?

Explicit guidance is given: 'Call it first to find the slug... skip it when the user already named the template.' It also names the sibling tools that depend on this lookup and clarifies that archived templates are excluded and an empty list is returned when nothing matches.

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 generic false annotations, the description discloses that every call is a new render, that live keys consume units while test keys are free and watermarked, that failures return status failed with an error code/message, and that download links expire. This is exactly the behavioral context an agent needs.

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 a dense paragraph rather than a bulleted list, but every sentence carries distinct information: purpose, output, alternative, template caveat, cost, failure handling, and link expiry. It is front-loaded with the core purpose and only slightly overlong.

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 an 8-parameter tool with no output schema and minimal annotations, the description covers return values (status, download_url), failure modes, link expiration, and cost. It could add a sentence about the async/wait behavior, but the schema already documents the wait parameter, so the description is complete enough 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?

With 100% schema description coverage, the schema does the heavy lifting for all 8 parameters. The description adds a useful caveat about stored templates rendering their published version and failing with template_not_found when null, but this is a single behavioral note rather than systematic parameter clarification, so the 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?

The description opens with a specific verb and resource: 'Creates a document by filling a stored template, or ad-hoc html, with data' and enumerates output formats. It explicitly contrasts with the sibling convert_to_pdf, so an agent can distinguish it immediately.

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 selection guidance: 'Use it to make a document from data; to turn an existing office file into a PDF, use convert_to_pdf.' It also tells when to use get_render for a fresh link and points to validate_template for pre-flight checking.

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 readOnlyHint/destructiveHint annotations, the description explains side effects (free, no units, nothing stored, no document), version selection (published else latest), what each mode checks, and the ok/diagnostics return contract including warnings leaving ok true. This is strong behavioral disclosure.

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 dense but every sentence earns its place and the main point is front-loaded. It is a single long paragraph that could be more scannable, but the length is justified by two distinct modes and a non-trivial return contract.

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 tool with four optional params, two modes, no output schema, and no required fields, the description is complete: it explains return shape (ok and diagnostics with severity, code, message, location), mode-specific checks, and how to handle warnings. Nothing an agent needs to invoke it correctly 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?

Schema description coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining how template is resolved (published/latest), that html is compiled offline, and that data is validated against a stored JSON Schema. This elevates the parameter guidance.

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 opens with a specific verb and object: 'Checks a template and its data without rendering', and immediately distinguishes it from render by stating no document is produced. It also separates the stored-template and html modes, so an agent can tell this tool apart from render and convert_to_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 explicit when-to-use guidance: 'Call it before render when you assembled the data yourself, or after writing ad-hoc html.' It names the render sibling as the follow-up operation, but it does not explicitly state when not to use the tool or name alternative validation paths.

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