Galley Render

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

Annotations mark this as a non-read-only, non-idempotent, open-world mutation; the description goes well beyond them by disclosing that omitted questions take their recommended answer, that a second call is refused, that every answer must go in one call, and that the operation is free. The refusal behavior corroborates idempotentHint=false rather than 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?

Front-loads the core action and uses short labeled sections ('Who answers') that scan well. It runs long relative to a 2-parameter call, but most sentences contribute routing or behavioral detail rather than 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, the description still closes the loop by telling the agent to poll get_import after and that the template is usually written in a few minutes. Combined with the annotation set, an agent has everything needed to 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 nested answer fields (question_id, value, path, answered_by) are already fully documented. The description usefully reinforces the value constraint ('nothing else is accepted') and the path rule, but adds little that the schema does not already carry, 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 ('answer the questions get_import shows on an import in `awaiting_answers`') and explicitly ties itself to the sibling that surfaces the questions. An agent can distinguish it from get_import without opening either 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?

Gives explicit when/when-not routing: answer yourself when evidence decides it (with concrete examples), ask the person when it concerns their business. It also names get_import as the follow-up step and warns to ask the person before submitting because a second call is refused.

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, it discloses that the link is single-use and short-lived, only works after a subscription exists, and is refused with a specific error if billing is not enabled. It also warns against constructing portal URLs manually, giving agents critical behavioral constraints the annotations do not cover.

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 detailed but every sentence earns its place: primary purpose first, then uniqueness, prerequisite, failure mode, and action guidance. The bolded error warning is placed prominently and the whole text remains scannable.

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 having no output schema, the description clearly conveys what is returned (a link) and what the agent should do with it. It covers prerequisites, alternatives, error handling, and follow-up steps, making it complete for correct invocation and downstream behavior.

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 and schema description coverage is 100%, so there is no parameter meaning the description must add. Per the baseline for zero-parameter tools, this earns a 4 rather than a lower score.

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 exact deliverable ('a link to the Stripe customer portal'), the intended user ('a human to open'), and the supported actions (change plan, update card, download invoices, cancel). It explicitly distinguishes itself from sibling tool `upgrade`, so an agent can select it unambiguously.

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 states exactly when to use it (human-driven plan/card/invoice/cancellation needs), when not to use it (before first subscription, use `upgrade`), and what to do on failure (`billing_unavailable`, point to support). It even forbids retries, leaving no ambiguity.

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 richly discloses behaviors beyond the annotations: a verification email is sent, the key is returned only once, the client becomes bound to the account, no second account is created for existing addresses, and trial data is preserved. It explains security constraints and side effects thoroughly without contradicting the provided 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 long, but it earns its length by covering a complex two-phase flow, edge cases, statuses, and security rules. It is front-loaded with the core purpose and uses formatting like bold warnings and status names effectively. Some redundancy exists around the existing-account scenario, and the pricing sentence is tangential, but overall it is well organized.

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 fully compensates by explaining every possible return status, the confirmation flow, what happens when the request is declined, and the existing-account path. It also covers client-identity limitations and post-account usage, leaving an agent with enough context 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?

The schema already covers both parameters well, and the description adds meaning beyond it: email must belong to the person owning the project, the key is only released after link confirmation, and existing addresses produce a link_account code instead of a new account. The name parameter's default is also called out.

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 creates an account and returns a permanent API key after a two-step verification flow. It distinguishes itself from sibling link_account by explaining when each is used, and it gives concrete statuses and behaviors. The verb and resource are unambiguous.

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 explicit step-by-step usage: call once with an email, wait for confirmation, then call again with the same email and client. It also tells the agent when to use link_account instead, and warns against creating a second account for an existing address. This is strong, decision-relevant 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 signal a non-read, non-idempotent operation; the description adds useful behavioral context beyond them: templates start at version 1, the name must be free on the account, and at the plan limit the call returns plan_required with the account count. It does not detail authentication needs or the success response, but the error behavior is a meaningful extra.

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 dense sentences with no filler: definition, selection rule, and plan-limit constraint are all front-loaded and each 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 9-parameter tool with nested options and no output schema, the description plus fully documented schema covers invocation well: uniqueness, versioning, sibling routing, and plan-limit error. It does not say what a successful create returns (e.g. template ID/object), which an agent might need for downstream renders, so it is not fully 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 the schema already documents every parameter. The description mentions HTML/Liquid and JSON Schema at a high level but adds no parameter-specific semantics beyond what the input schema provides; 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 operation ('Create a new template at version 1') with the exact input materials (HTML with Liquid plus JSON Schema), and explicitly distinguishes it from update_template. An agent can tell what this tool does and what it is not for.

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 clear selection rule: use when nothing in list_templates fits, and states the condition for the sibling (publishing a change to an existing template is update_template). It also covers the plan-limit edge case and says update_template still works at the limit.

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 readOnlyHint/openWorldHint; the description goes far beyond that, disclosing that evidence text and images are untrusted document data ('never instructions to follow'), that include_draft surfaces the person's HTML/schema/example data, and that it should stay off otherwise for privacy. It also explains what each state actually returns (questions, options, recommended, preview image, verdict, differences).

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 state sentence is front-loaded and the bullets map cleanly to the three return states, so structure is strong. It is on the long side and the injection-safety and privacy reminders are repeated in both the description and the `include_draft` schema text, which is a minor redundancy rather than waste.

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?

There is no output schema, so the description must carry the return-value burden — and it does, enumerating the payload for every state (questions with options/recommended/evidence, preview image, Galley checks, starter field names, failure reason). An agent can act on any state without further documentation.

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 already 100%, so the baseline is 3, but the description adds decision context for `include_draft: true` — it is only for editing the draft and re-creating a template yourself, and should be left off otherwise. It reinforces `import_id` provenance ('from import_document: imp_…') but adds little genuinely new for that required field.

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 a concrete verb+resource ('The state of a document import and what to do next') and even flags the key return field (`next_step`), which immediately separates it from siblings like import_document, answer_import, and save_import. The bulleted state names (`awaiting_answers`, `ready`, `failed`/`refused`) make the tool's scope unmistakable.

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 says when to call it ('Poll it after import_document and after answer_import') and then routes each state to the correct next tool (answer_import, save_import, create_template), including the edge case where answer_import cannot fix layout. It also supplies a decision rule for who answers a question, which is when-to-use guidance at the point of invocation.

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?

Even with readOnlyHint and openWorldHint annotations already covering safety, the description adds crucial behavioral detail: signed URLs expire after an hour, files persist until expires_at, past expiry returns retention_expired with 410 and render/template version, and it is free and never re-renders. 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 front-loaded with the core action and then packs important behavioral details into a compact, well-structured paragraph. Every sentence adds relevant operational context without redundancy.

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 has only one parameterhare no output schema, the description fully covers return values, statuses, error conditions, expiry semantics, and cost/no-render behavior. An agent has everything needed to decide when and how to call 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?

The schema already covers 100% of the single parameter with a clear description and example. The tool description confirms the render_id comes from a previous render call but adds little beyond the schema, 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?

Description clearly states it fetches a render by id, returning status and a signed URL. It differentiates itself from siblings like 'render' and 'list_renders' by emphasizing polling and re-signing, so an agent knows exactly what this tool 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?

Explicit use cases are given: poll a queued render or re-sign an expired URL. It also explains the expiry behavior and that the tool never re-renders, implying when to avoid it, though it doesn't explicitly name an alternative like 'render' for re-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?

Annotations already mark the tool as read-only and open-world, so the safety profile is covered. The description adds value beyond annotations by stating the tool is free and by specifying exactly what the response contains, which is especially useful because no output schema exists.

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 with no redundancy: the first front-loads the core purpose, the second conveys a critical usage warning, and the third notes cost. 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?

For a two-parameter retrieval tool with full schema coverage and read-only/open-world annotations, the description plus schema fully equips the agent: what to pass, what to expect back, why it matters, and that it is free. The enumerated return values compensate for the missing output 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 the schema already fully documents the template parameter (including version pinning) and include_source. The description adds no parameter-specific detail beyond pointing to the 'data' argument contract, so the baseline score of 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?

The description uses a specific verb ('Fetch') and clearly identifies the resource ('one template version') while enumerating the exact payload components: JSON Schema, default render options, example payload, and HTML source. This immediately distinguishes it from sibling tools like get_render 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?

The description explicitly instructs the agent to read the schema before rendering, positioning this tool as a prerequisite for render or validate_data workflows. It does not explicitly name alternative tools for rendered output, but the usage context is 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?

Goes well beyond annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false, idempotentHint=false) by disclosing quota accounting ('counted when one starts — failed and refused imports are not counted'), that nothing is billed per import, data handling (sent to Anthropic's Claude API, 30-day retention, Galley deletes its copy within 7 days), refusal categories for sensitive documents, and the one-time 15-minute upload link semantics.

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?

Length is justified by the multi-step workflow, prerequisites and policy surface, and the purpose is front-loaded before the ingestion-modes section. Some content (upload/file_base64 tradeoffs, exactly-one rule) repeats the schema descriptions, which is the only real redundancy.

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, open-world tool, the description covers inputs, prerequisites, quota/billing, privacy, refusal behavior, and the follow-up call sequence an agent needs to complete the task. Nothing material is left to inference.

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 already 100%, so the baseline is 3; the description lifts it by explaining the selection logic among upload/file_url/file_base64 and the 'send exactly one' constraint, plus the token-cost rationale against base64. It largely narrates what the schema already documents, so it stops short of a 5.

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?

Opens with a specific verb+resource: turning an existing document into a Galley template that reproduces its look and yields a fillable JSON Schema. It also implicitly separates itself from create_template (from scratch) and save_import (the finalization step) by noting 'Nothing is a template until it is saved.'

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 each ingestion path (upload for chat, file_url for a pasted link, file_base64 only when a client holds bytes in code) and enforces 'send exactly one.' It also gives the downstream sequence (poll get_import, answer_import, save_import), the create_account prerequisite, and the plan_required failure mode.

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, the description discloses that the credential is checked once and dropped, that only an account id and a minted client key are stored, that unlink_account revokes the binding, and that possession of the client id becomes a credential. This is exactly the behavioral context an agent needs for a linking operation.

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 longer than average but front-loaded and well-structured with bold lead-ins that make it scannable. Nearly every sentence carries setup, security, or eligibility guidance; only the stray trailing 'Free.' feels extraneous.

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 mutating, auth-related tool with no output schema, the description covers prerequisites, eligibility, both proof methods, credential lifecycle, revocation, and security warnings. An agent has everything needed to decide whether and how to 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?

The schema already covers both parameters with examples, constraints, and lifecycle details, so the baseline is 3. The description adds selection guidance—api_key when the key is on hand, link_code when the user prefers not to paste a key—and connects link_code to create_account, which raises it above 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 opens with a precise statement of what the tool does: 'Point this MCP client at an account you already have' and ties it to a concrete effect (stopping header-less calls from spending the keyless trial). The title and body also clearly separate it from create_account and unlink_account.

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 says when to use this tool (clients that cannot set HTTP headers), tells the agent to prefer a header-based approach when possible, and states the eligibility requirement that the client have an identity of its own. It also gives two concrete ways to authenticate and when to choose each.

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 openWorldHint=true, lowering the bar. The description adds behavioral specifics: 'newest first' ordering, inclusion of status and template version, and signed URLs only for successes, plus the note that it is 'Free.' These go beyond the annotations and help an agent understand what the call returns and its side-effect-free nature.

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 with no wasted words. It front-loads the primary function and ordering, then adds practical use cases and a cost note, all in a compact, scannable format.

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 simple tool with one optional parameter, read-only annotations, and no output schema, the description covers the essential information: what is returned, ordering, and when to use it. It does not mention response format details (e.g., array shape) or pagination beyond the limit, but those are minor given the tool's simplicity.

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%—the schema fully documents the 'limit' parameter with min, max, and default. The description does not add any new meaning to the parameter; it simply omits it. Per the rubric, a baseline of 3 is appropriate when the schema carries the parameter documentation.

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 lists recent renders on the account, ordered newest first, and specifies the included fields (status, template version, signed URL for successes). It also distinguishes itself from siblings like get_render (which fetches a specific render) and render (which creates one) by its listing focus and explicit use cases.

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 concrete usage scenarios ('finding a render whose id you lost' and 'checking what a batch did'), which tells an agent when to choose this tool. It does not explicitly name alternatives or state when not to use it, but the context is clear enough for correct selection among siblings.

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 openWorldHint=true, so safety is covered. The description adds useful behavioral context beyond annotations: it says the output includes the latest version number and an `origin` field with meanings (`library`, `import`, `own`), and notes that trial accounts start with a starter library. It does not discuss pagination, authentication needs, or rate limits, but for a simple read-only list tool this is a strong addition.

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 action and usage hint, then adds origin semantics and trial-account behavior. Every sentence contributes useful information, though the length is slightly longer than strictly necessary (e.g., 'and more' and 'Free.' could be trimmed without losing much). Still efficient overall.

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 must convey return contents, and it does: templates, latest version number, and the `origin` field with its three values. It also covers the trial-account starter library. It omits details like pagination or the full response shape, but for a simple list tool this is largely 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?

The tool takes zero parameters and the schema is an empty object, so there are no parameter semantics to explain. Per the rubric, zero parameters yields a baseline of 4; the description appropriately adds no unnecessary parameter detail.

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 ('List') and resource ('templates on this account') and adds the returned field ('latest version number'). It distinguishes itself from siblings like get_template (singular retrieval) and explains origin values tied to create_template and import_document, so an agent can identify its role without opening another 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 clear context for use ('Start here: rendering needs a template, and this says which ones exist') and mentions related tools (import_document, create_template) when explaining origin. However, it does not explicitly state when not to use it or name a direct alternative for inspecting a single template (e.g., get_template), so it stops short of full when/when-not 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?

Adds substantial behavior beyond the annotations: deterministic and cached renders with `cached: true`, per-page/per-image billing with cache hits never billed, a first-call trial token of 10 pages/images, and a `warnings` output for unused fields or missing language text. None of this is derivable from readOnly/openWorld/idempotent hints alone.

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-loaded with the core action and the sync/async split, then caching/billing, then the language guidance. Every paragraph carries information, though the lang/labels passage is somewhat dense and could be tightened.

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 supplies the return contract itself: `status: succeeded` with a url, or `status: queued` with an id, plus `cached` and `warnings`. Combined with the rich schema and the async/get_render path, an agent has everything needed to call 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?

Schema coverage is already 100%, so the schema carries most parameter detail. The description still adds real meaning: options are part of the cache key so visually-identical calls can be distinct renders, and version pinning (`invoice@3`) matters for shipped code because new versions change output and cache keys.

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 (render), the resource (template + JSON payload), the output formats (PDF/PNG/JPG) and the return value (signed URL). The line 'This is the one tool most calls need' positions it against the sibling set unambiguously.

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 routes the agent: sync payloads return a url, while webhook_url/async/large payloads queue and must be polled with get_render. It also points to get_template for the schema, validate_data for a dry run, and list_templates for inventory. Clear when-to-use and which alternative to reach for.

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 substantial behavior beyond the annotations: it's destructive (destructiveHint=true) only in the second call with confirm_saved, the key is shown once and cannot be recovered, and it does not revoke on the first call to avoid downtime. This is additional context that the annotations do not provide, directly aligning with the destructive hint.

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 well-structured with bold headers and paragraphs, front-loading the key facts. It is concise despite its length, with each sentence earning its place, and it uses formatting to make the two-call process easy to follow.

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 complexity of a two-call destructive operation with no output schema, the description is highly complete. It covers all necessary steps, pitfalls, and edge cases, including what to do when the user has no key. No missing information is apparent.

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 documents both parameters. However, the description adds crucial meaning: it explains the two-call sequence, the need to use the id from 'other_live_keys', and warns against guessing the id. This is a moderate addition over the schema, so a 4 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 a specific verb ('mint' and 'retire') and resource ('API key'), and distinguishes this tool from the sibling 'create_account' by explaining that it cannot help someone holding nothing. The title and description work together to convey the purpose.

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 explicitly says when to use the tool ('key has been lost, leaked...') and when not to ('Needs a key on the connection or a linked client — it cannot help somebody holding nothing. That case starts at create_account'). It also provides a detailed usage protocol for the two-call process, including the need to wait for confirmation before revoking.

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 beyond the annotations: it confirms idempotency ('Saving again returns the same template'), discloses plan-limit behaviour with `plan_required`, explains retention (import copy deleted after 7 days, template persists), and states the billing model (free, renders bill as renders). Annotations say nothing about limits, retention, or billing.

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 core action and precondition, then layers limits, idempotency, retention, and billing in short clauses with no filler. Dense but each sentence carries distinct operational information.

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 usefully spells out the return (template ref `name@1`, fields, render instructions), and covers the lifecycle, quota, and cost facts an agent needs before calling. Complete for this operation.

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 schema already documents all three parameters including the name defaulting rule and the pattern. The description repeats the `name` default rather than adding new syntax or constraints, 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 ('Save a `ready` import as a template on this account') and pins the precondition that the import must be `ready`. This clearly distinguishes it from create_template (build from scratch) and update_template (publish changes to an existing template).

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 trigger ('once the person has seen the preview and says it is right') and points to `update_template` as the tool for later changes, but does not explicitly state when not to use this versus `create_template`.

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, it discloses concrete effects: binding deletion, key revocation, fallback to keyless trial, own API key untouched, and safe when nothing is linked. This is rich behavioral context beyond the readOnly/destructive/idempotent hints.

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 action, follows with consequences, and then gives usage scenarios. Every sentence adds decision-relevant information, including safety and cost, without padding.

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, no-output-schema tool, the description fully covers when to call it, what happens, what does not happen, and post-call behavior. Nothing needed 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?

The tool takes zero parameters and schema description coverage is 100%, so there is no parameter burden for the description to carry. Baseline 4 applies; no additional parameter detail is needed.

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 'Undo `link_account`' and specifies the resource and effect: the binding is deleted and the client key revoked. This clearly differentiates it from its sibling link_account and from account-level operations like create_account or account closure.

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 conditions for use: on any machine that is not yours, or whenever a personal connector URL or client id may have been exposed. It also states what it is not for ('does not close an account') and frames link_account as the inverse operation.

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, the description discloses important side effects: old versions remain unaffected, cached renders stay valid, the new version starts with a cold cache, and engine/schema/options/example are inherited unless sent. It also states that publishing is free, which is useful open-world context. There is no contradiction with the 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 four tight sentences with the core purpose first, then behavioral guarantees, then the minimal-invocation rule, then the cost signal. Every sentence earns its place and there is no redundant wording.

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 9 parameters and a nested options object, the description plus the fully documented schema covers the publishing workflow, versioning semantics, caching, inheritance, and pricing. The main gap is that it never describes the success return value or how to reference the newly published version, and there is no output schema to fill that in.

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 coverage, the schema already documents each parameter, so the baseline is 3. The description adds cross-parameter meaning by naming which fields are inherited (`engine`, `schema`, `options`, `example`) and by stating that a source-only change requires only `template` and `source`. This is useful but modest; most per-parameter detail is correctly left to 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 leads with a specific verb and resource: 'Publish a new immutable version of an existing template.' It further distinguishes the tool from a plain update by explaining versions are never edited in place, and it uses `invoice@2` as a concrete anchor, so an agent can tell this apart from create_template even 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 clear context for when the tool applies: publishing a new immutable version rather than editing an existing one, and it tells agents that a source-only change needs only `template` and `source`. It does not explicitly name alternatives like create_template or state when not to use it, so it stops short of full routing 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, the description discloses that nothing is charged until the human completes Stripe's page, that the plan goes live within seconds, and that billing-unavailable deployments return a deliberate 503 rather than a fake link. It also warns not to construct checkout URLs or retry.

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 summary sentence is front-loaded and every paragraph carries important behavioral or routing information. The only structural blemish is the stray 'Free.' fragment near the end, which is ambiguous and does not clearly earn 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 tool with no output schema, the description fully covers the return value (a URL), prerequisites, error behavior, alternatives, and what happens after checkout. An agent has enough context to invoke it correctly and handle failures appropriately.

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 covers both parameters at 100% with detailed descriptions, including prices, limits, the 'no free' caveat, and interval default. The tool description itself adds no further parameter-level meaning, so the high-coverage baseline of 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?

The first sentence names the exact action and result: 'Get a Stripe Checkout link for a paid plan, for a human to open.' It also explicitly states what the tool cannot do ('cannot subscribe anybody'), which sharply differentiates it from billing_portal and create_account.

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 explicit triggering conditions ('quota_exceeded' or 'plan_required'), names the sibling tool for plan changes/cancellation ('billing_portal, never this'), and specifies a prerequisite (verified email via 'create_account'). It even explains how to confirm the result with '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 declare readOnlyHint and openWorldHint, so the read-only nature is disclosed. The description adds behavioral specifics: it is free, and it enumerates the exact data returned (spent, limits, trial remaining). This goes beyond annotations and helps the agent know what to expect. No contradiction.

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 single, information-dense sentence that front-loads the purpose, then adds a usage hint and cost note. No wasted words; every phrase adds value.

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 tool with no output schema, the description is complete: it states what it queries, what information it returns, when to use it, and that it's free. Nothing an agent needs to decide whether to call it 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 and an empty schema, so there are no parameters to document. Baseline 4 applies; the description doesn't need to compensate for any schema gaps.

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: it shows the account's spent and remaining budget/limits. It lists concrete metrics (renders, billable units, cost, free-tier allowance, monthly spend cap, trial pages/images), which distinguishes it from sibling tools like billing_portal (billing management) and render tools. It is not a tautology.

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 provides a clear usage scenario: 'Check it before a large batch.' This implies when to use it. It doesn't explicitly name alternatives or exclusions, but it's evident that this is for querying usage/limits, separate from billing actions. So it has clear context but no explicit exclusions.

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 readOnlyHint and openWorldHint; the description goes well beyond by stating no cost, no render, the exact error shape (field path, expected type, received value, acceptable value), the `warnings` structure with `did_you_mean`, and the conditional handling of `lang`. That is rich, decision-relevant behavior for a validation 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?

Front-loaded with the core action and its zero-cost guarantee, then the return contract. Three dense sentences; the first is long but every clause carries information, so there is little waste.

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?

No output schema exists, and the description compensates fully by describing both the error payload and the `warnings` list, plus cross-references (get_template, list_templates) for the schema-dependency caveat. An agent has everything needed to call 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 coverage is 100%, establishing a baseline of 3, but the description adds meaning the schema does not: `lang`/`labels` at the root are honoured only if the template's schema declares them, otherwise they surface as unknown fields. That clarifies actual param behavior beyond the field descriptions.

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: dry-run a `data` payload against a template's JSON Schema and return the errors a render would raise. 'Costs nothing and renders nothing' cleanly separates it from the sibling `render` tool without needing 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?

Gives clear usage contexts: 'Use it before a batch, or whenever you are assembling a payload from somewhere you do not control.' It implies the render alternative by describing exactly the errors a render would raise, but never names `render` explicitly as the tool it substitutes for.

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 readOnlyHint and openWorldHint, and the description adds genuinely useful behavior beyond them: the call itself is free and consumes no renders ('Free, and it renders nothing'), and the three auth modes (header/binding/trial) map to observable failure signatures such as quota_exceeded with an unrecognized limit. 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?

Two dense paragraphs, each earning its place: the first front-loads the resource and return fields, the second gives when-to-call and interpretation rules. No filler or redundancy.

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 identity tool with no output schema, the description covers the return fields, quota meaning, authentication variants, a usage rule, and a troubleshooting scenario. An agent has what it needs to decide when to call whoami and how to interpret its 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 there is no parameter burden for the description to carry; the empty schema and 100% coverage fully document invocation. Baseline 4 applies, and the description appropriately says nothing about arguments.

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 identifies a concrete resource — the account behind the current connection — and enumerates exactly what it returns: id, plan, renders_remaining, and authentication origin. It also carves out a distinct niche from siblings by stating the auth-method field is 'the part no other tool answers,' so an agent can distinguish whoami from usage, billing_portal, and the rest.

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 direct call triggers: 'Call it before a batch' and 'the moment anything about quota surprises you,' plus a concrete diagnostic workflow for quota_exceeded errors that point to a keyless trial. It does not spell out when-not-to-call or compare against sibling tools like usage, so it falls just 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.