Galley Render

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?

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?

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, so the description doesn't need to restate that. It adds useful context: 'Free' (cost) and the presence of a starter library for new trial accounts. However, it doesn't disclose potential pagination, sorting, or response format, which are minor gaps for a list 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 sentences, front-loaded with the primary action, and each sentence adds value. 'Start here' is a helpful orientation, and the mention of the starter library and cost is concise and relevant.

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 list operation with no parameters and no output schema, the description covers the key purpose, expected contents (starter library), and a note on cost. It could mention the return format (e.g., list of template IDs and versions), but the description already hints at the version number, making it 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?

Tool has zero parameters, so baseline is 4. The description adds no parameter info, which is unnecessary; the schema is empty and already self-explanatory.

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?

Clear verb+resource: 'List the templates on this account' with a specific output detail (latest version number). Differentiates from siblings by positioning it as the starting point for rendering, distinguishing it from get_template or create_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?

Provides explicit usage guidance: 'Start here: rendering needs a template, and this says which ones exist.' This tells the agent when to use it (before rendering) without naming alternatives, but the context is clear enough.

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 annotations (idempotentHint, openWorldHint), the description discloses caching behavior ('deterministic and cached', `cached: true`), billing rules (per page/image, cache hits free), a free trial, sync/async return statuses, and even error handling for blocked assets via on_blocked_asset. It adds substantial operational context that annotations alone do not provide, with 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 long but every sentence earns its place. It front-loads the core purpose, then progressively covers sync/async, caching, billing, and trial. There is no filler; each paragraph adds essential behavioral detail. Structure is logical and 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?

Given the tool's complexity (nested options, multiple output formats, async flows), the description covers all key aspects: return statuses with URLs/ids, caching, billing, trial, error behavior, and cross-references to related tools. It even hints at response shape (status, url, cached) despite lacking an output schema. 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?

Even though schema coverage is 100%, the description enriches parameter understanding: it explains that options are part of the cache key, clarifies template version pinning semantics (`invoice@3`), and links data to validation via validate_data. This goes well beyond the schema's field descriptions, giving the agent practical 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 precise verb+resource: 'Render a template plus a JSON payload into a PDF, PNG or JPG and return a signed URL.' It also distinguishes itself from siblings by calling itself 'the one tool most calls need' and later references get_render, validate_data, get_template, and list_templates, making the primary purpose 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 explains when to use the sync vs async path, when to call get_render for queued jobs, and points to validate_data for dry-runs and get_template for schemas. It also advises pinning template versions in production. This is direct guidance on when to use this tool versus alternatives, with 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 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?

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 already declare readOnlyHint=true and openWorldHint=true, so the agent knows it's a safe, non-mutating operation. The description adds valuable context: it costs nothing, renders nothing, and returns specific error details (field path, expected type, received value, accepted value). This goes beyond the annotations and helps the agent understand the tool's behavior.

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 and front-loaded. The first sentence states the core function and output. The second sentence adds cost/behavior context. The third gives concrete usage guidance. No wasted words.

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

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

For a validation tool with readOnlyHint and openWorldHint annotations, the description is quite complete. It explains the return value (errors with field path, expected type, received value, accepted value), the cost (nothing), and the usage context. It doesn't describe the exact output format, but since there's no output schema and the description already lists the error components, this is a minor gap.

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 both parameters. The description adds meaningful context for the template parameter: how to pin versions (invoice@3) and the warning that new versions change output and cache key. It also clarifies that data is checked against the template's JSON Schema and nothing else. This adds value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: dry-run a data payload against a template's JSON Schema and return the exact errors a render would raise. It specifies the resource (template's JSON Schema) and the verb (validate/dry-run), and distinguishes it from the render tool by emphasizing it costs nothing and renders nothing.

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 it: before a batch, or whenever assembling a payload from an untrusted source. It also implies when not to use it (when you want an actual render) by stating it renders nothing. This is clear 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 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.