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

readOnlyHint=true already tells the agent this is a safe read, so the description only needs to add context. It does add a time window ('this month's') and the plan scoping, which are useful behavioral facts not present in the annotations or the empty schema, but it does not clarify what counts as a 'render' (PDFs vs template renders) or when the count resets.

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?

A single front-loaded clause with no filler; every item listed corresponds to a distinct value the caller receives. It is a fragment rather than a sentence, which reads slightly clipped but wastes nothing.

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 parameters and no output schema, the description carries the burden of conveying what comes back, and it enumerates the key fields. However, it omits the reset period and the unit definition of the render count, both of which an agent needs to reason about a quota result.

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 parameter-wise the description needs to explain. The description does implicitly confirm the scope is the caller's own plan, which is consistent with a parameterless call.

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 names the resource (this month's render count, limit, remaining quota, rate limit for the plan) precisely enough that an agent can distinguish it from all siblings (render_pdf, screenshot, list_templates, render_template, verify_receipt), none of which report quota. It lacks an explicit verb, reading as a list of returned values rather than a statement of action, 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?

There is no statement of when to call this, no prerequisites, and no reference to alternatives. An agent can infer it is a pre-flight check before rendering, but that inference is never stated in the description.

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 already establishes the safety profile, and the description adds real behavioral context beyond it: the result spans both user-saved templates and a fixed set of built-ins, and each entry carries an id and a name. It does not state ordering, paging, or what a 'saved' template entails, which are minor for a zero-parameter list call.

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?

A single front-loaded sentence with no filler. The return contents come first and the enumerated built-ins follow as concrete detail, so nothing needs trimming.

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-only, no-output-schema tool, the description covers enough: it says what the list contains and names the built-in members. It could add one clause tying ids to render_template, but nothing essential to calling 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?

The tool takes no parameters, so there is nothing for the description to disambiguate; baseline applies. The description correctly avoids inventing filter or paging semantics the schema does not support.

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+resource ('List ... templates') and goes further by naming what comes back (ids and names) and enumerating the built-in templates. It is clearly distinct from render_template, render_pdf, and verify_receipt, though it never names a sibling to reinforce that separation.

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?

Usage is only implied: an agent can infer this is a discovery step before render_template, but the description never says 'use this to find a template id before rendering' or state any when-not conditions. Adequate but leaves the workflow inference to the agent.

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 supplied, the description carries the full burden, and it does add real behavioral context: statelessness ('Nothing is stored by pagenull'), the returned artifacts (PDF, signed receipt, warnings, quota), and the base64-vs-save_to choice. It omits auth requirements, rate limits, quota magnitude, and failure behavior, leaving meaningful gaps for a tool whose result is a file.

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 short sentences, front-loaded with the core purpose and immediately followed by the key calling constraint. The phrasing 'with pagenull' and the sentence fragment 'Returns the PDF..., its signed receipt, warnings and quota' are slightly compressed but nothing is redundant.

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 12-parameter tool with nested margin/options objects and no output schema, the description covers the essential unknowns: return form, side artifacts, file-writing behavior, and statelessness. What remains missing — auth, quota size, and the unpinned options passthrough — is documented in the schema or externally, so the description is largely sufficient.

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 already 83%, so the schema documents most parameters. The description still adds genuine meaning beyond it by stating the mutual-exclusivity rule between html and url (the schema does not enforce a oneOf) and by explaining that save_to replaces base64 output with a written file. Landscape, margins, and options rely entirely on 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 names a specific verb and resource ('Turn HTML or a public URL into a PDF'), so an agent can immediately tell this is an HTML/URL-to-PDF renderer rather than a template renderer or screenshot tool. It does not, however, explicitly distinguish itself from siblings like render_template or screenshot, which plausibly overlap.

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?

Usage is implied by the input constraint 'Send exactly one of html or url,' which tells the agent how to call it but not when to prefer it over render_template or screenshot. No explicit when-not guidance or mention of alternatives appears anywhere in the description.

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 supplied, so the description carries the disclosure burden and does add some value by stating the return is a PDF delivered like render_pdf. It says nothing about quotas, template-not-found failures, or that a test render is free and watermarked (that lives only in the schema). Given there are no annotations, more behavioral context would be expected.

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 short sentences, front-loaded with the action and output format, with no wasted wording. The cross-reference to render_pdf is compact and lands before any procedural 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?

For a 7-parameter tool with nested objects and no output schema, the description states the return form (a PDF, base64 or written to disk per save_to) which is the key missing piece otherwise. The fully documented schema covers the rest, though error and quota behavior remain unaddressed.

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 every parameter is already documented including test, save_to, overwrite, and the template id source. The description only echoes 'with JSON data' for the data parameter, which does not exceed the schema. Baseline 3 applies when the schema does the heavy lifting.

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 names a specific verb and resource (render a saved or built-in template) and the output format (PDF), so an agent can tell it apart from render_pdf and screenshot at a glance. It does not fully clarify the boundary with render_pdf, since it only references it as a return-format analogue rather than stating what render_pdf itself does.

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?

Usage is implied by the 'saved or built-in template' phrasing and the id reference to list_templates, so an agent can infer this is the tool for template-driven PDFs. There is no explicit when-to-use versus render_pdf, and no guidance on when a template is worth using over raw rendering.

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 and delivers the key traits: the URL must be public, the result is returned inline unless save_to is set, and 'Nothing is stored by pagenull' discloses statelessness/privacy. It says nothing about failures, timeouts, or quota consumption, which matter for a 12-param render tool.

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 core action, then the exclusive-or rule, then the return behavior. No filler or restatement of the title.

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 a nested passthrough `options` object and no output schema, the description covers input source, output format, return vs file, and statelessness. Remaining gaps (error/timeout behavior, quota implications of non-test renders) are minor and partly covered by schema descriptions.

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 75%, so the schema handles most parameters, but the description adds a real constraint the schema does not encode: html and url are mutually exclusive, exactly one required (required list is empty). It also clarifies the save_to-vs-return branch, adding meaning beyond the property docs.

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 first sentence gives a specific verb+resource+output ('Render HTML or a public URL to a PNG or JPEG image'), which implicitly separates it from render_pdf by output format. Differentiation from siblings is achieved through the format keyword rather than naming the alternative, so it stops 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?

'Send exactly one of html or url' is an invocation constraint, not a when-to-use rule. Nothing tells the agent when to choose this over render_pdf, when to use test mode (only the schema hints at quota), or when save_to beats inline base64.

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 readOnlyHint, the description discloses Ed25519 signature checking with the publisher's key, optional exact-output file verification, and that the file never leaves the machine. It does not describe what the tool returns or how invalid signatures are reported, but the key behavioral traits are covered.

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 tight sentences, front-loads the core verification action, and includes only useful details about file inputs and privacy. No wording is wasted.

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 inputs and privacy well, but with no output schema and no explanation of return values or failure modes, an agent lacks the full picture of what verification results look like. For a cryptographic verification tool, the description should say more about outcomes.

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 schema already names and documents all four parameters. The description adds useful semantics by clarifying that the file may be provided as file_path, pdf_base64, or sha256, and reinforces the local-only processing constraint.

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 and resource: check a receipt's Ed25519 signature, optionally verifying that a file matches the output it describes. This clearly distinguishes verify_receipt from sibling tools like render_pdf and list_templates.

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 the optional file-checking use case and lists the three accepted ways to supply the file: file_path, pdf_base64, or sha256. It does not explicitly name when not to use it or compare it with siblings, but the verification context is clear.

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