Galley Render

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

The description discloses key behavioral traits beyond annotations: the two-step verification flow, that the key is only released after link click, that the key is shown only once, and that the trial is upgraded in place. It also mentions the free tier limit and pricing URL. This adds significant context beyond the annotations (readOnlyHint=false, idempotentHint=true, etc.) and does not contradict them.

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 and front-loaded: it starts with the core purpose, then explains the two-step flow, then covers edge cases and constraints. Every sentence adds value, and the length is appropriate for the complexity of the tool.

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 (two-step verification, one-time key release, in-place upgrade), the description covers all necessary aspects: how to call it, what to expect, what to do after, and important caveats. No output schema exists, but the description explains the return values ('status: pending_verification' and the API key).

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. The description adds meaning by explaining the email's role in the verification flow and warning against using a made-up email. It also clarifies the 'name' parameter defaults to the local part of the email. This goes beyond the schema's basic 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?

The description clearly states the tool's purpose: converting a keyless trial into a real account and obtaining a permanent API key. It uses a specific verb ('create') and resource ('account'), and the title reinforces this. It distinguishes itself from siblings by focusing on account creation rather than template/render operations.

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 explicit step-by-step usage: call once with email, wait for verification link click, call again with same email to get the key. It also states when not to use it (e.g., not for trial operations) and mentions the in-place upgrade preserving trial data. This is clear guidance for an agent.

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

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

Annotations already convey that this is not read-only and not idempotent. The description adds useful behavioral context beyond them: the tool creates at version 1, requires an unused name, and is not for updating existing templates. 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 tight and front-loaded, with clear selection guidance and no redundant restatement of the title. The trailing 'Free.' is slightly ambiguous and adds only marginal value, keeping it from a perfect score.

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 9-parameter nested schema, the description plus the exhaustive schema is sufficient for an agent to select and invoke the tool correctly. The sibling differentiation is handled, and no critical invocation detail appears missing, although the lack of an output schema means response behavior is left unspecified.

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

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

Schema description coverage is 100%, and the schema provides rich explanations for parameters including engine trade-offs, source expectations, options semantics, and expected_pages. The tool description itself adds little parameter-level detail, which is fine because the schema carries the burden.

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

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

The description names a specific verb and resource: 'Create a new template at version 1 from an HTML document with Liquid expressions, plus a JSON Schema for its data.' It also distinguishes itself from siblings by explicitly marking 'update_template' as the alternative for publishing changes to existing templates.

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

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

It gives an explicit selection rule: 'Use this when nothing in list_templates fits.' It also states the precondition that the name must be free and the alternative tool to use for existing templates, which fully orients the agent.

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

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

Beyond the readOnlyHint annotation, the description adds meaningful behavior: signed URLs are short-lived while the stored object persists, the tool is free, and it never re-renders. This clarifies side-effect expectations without contradicting 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?

Three sentences carry the purpose, usage scenarios, and behavioral caveats with no filler. The core action is front-loaded and every remaining clause adds decision-relevant 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 still names the return content (status and freshly signed URL) and the two main calling scenarios. It does not enumerate possible status values or error behavior, but for a one-parameter read-only tool 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 coverage is 100%, and the input schema already documents render_id with an example and the note that it comes from a previous render call. The tool description only adds 'by id', so it provides no meaningful semantic value beyond the schema; 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?

The description states a specific verb and resource: 'Fetch a render by id.' It also names the exact outputs (status and a freshly signed URL), so an agent can distinguish this from sibling tools like render, list_renders, or get_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?

The description gives two explicit use cases: polling a queued render and re-signing an expired URL. It does not explicitly name alternatives or say when not to use it, so it stops short of a full when/when-not guide.

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?

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, the description discloses caching and determinism, succeeded vs. queued statuses, billing behavior, and the trial-token minting side effect. It also clarifies that cache hits are free and instant, which is materially useful for an agent deciding whether and how to invoke the 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?

The description is tightly organized, front-loading the core action and then layering sync/async behavior, caching, billing, and auth. Every sentence carries operational value and none merely repeats the title or schema.

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

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

The description covers what the tool does, what response statuses to expect, how to retrieve async results, billing consequences, caching semantics, and how authentication starts. This is enough for an agent to invoke it correctly without an 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 baseline is 3, but the description adds meaningful cross-parameter context: webhook_url and async drive the queued path, options and template version participate in the cache key, and large payloads trigger async handling. This goes beyond the schema without replacing it.

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

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

The description states a precise action and resource: render a template plus JSON payload into PDF, PNG, or JPG and return a signed URL. It also distinguishes itself by calling out that this is the one tool most calls need, separating it from siblings like get_render, get_template, and validate_data.

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 routing guidance: use get_render for queued jobs, get_template for schemas, validate_data for dry-runs, and list_templates to discover templates. It also explains when async/webhook forces the queued path, so an agent knows how to choose between this tool and alternatives.

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 (which only mark it as non-read-only, non-destructive, and open-world), the description discloses key behavioral traits: immutability, cache behavior (old cache remains valid, new version starts cold), inheritance rules for optional fields, and that the operation is free. This is substantive context an agent needs.

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

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

Two sentences, both dense with information. The first sentence states the core purpose and immutability; the second covers cache, inheritance, and minimal usage. No filler or repetition of schema content.

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 publish operation with no output schema, the description covers the critical behaviors (immutability, cache, inheritance, cost) and the schema documents all parameters thoroughly. The only minor gap is the absence of any mention of what the response contains or what happens on invalid template names, but these are not blockers for correctly invoking the tool.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value beyond the schema by summarizing the inheritance pattern (engine, schema, options, example are inherited) and showing how that reduces the required parameter set. It does not add per-parameter details beyond schema, but the combined guidance is helpful.

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 ('Publish') and resource ('new immutable version of an existing template'), making it immediately distinct from create_template. It also clarifies the versioning model ('invoice@2 keeps rendering exactly as it did'), which eliminates ambiguity about what the 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?

The description clearly implies when to use this tool (for existing templates) and gives practical guidance on minimal calls ('a source-only change needs only template and source'). However, it does not explicitly name alternatives or state when not to use it, such as 'use create_template for a new 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?

The description adds meaningful behavioral context beyond the readOnlyHint annotation by detailing what the report contains and noting that it is free to call. It does not describe response format or potential pagination, but the annotations already signal safety and open-world output.

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

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

Three sentences each carry purpose: what the tool reports, when to use it, and the cost implication. The first sentence is dense with an em-dash and a long list, but it is still readable and front-loads the core 'what you have spent and what is left' message.

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 usage report with readOnlyHint and openWorldHint already set, the description covers everything an agent needs: the report's contents, the recommended timing, and that it is free. No output schema exists, but the description sufficiently describes the returned information without needing to enumerate fields.

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

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

The tool has zero parameters, so the input schema is fully complete by default. The description adds value by explaining what data the report exposes, which is more than the schema can convey.

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 identifies the tool as an account usage and limits report, enumerating what it covers: renders, billable units, cost, free-tier allowance, monthly spend cap, and trial render count. The imperative 'Check it' makes the read action explicit, and this is clearly distinct from the sibling creation, rendering, and template tools.

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 a specific trigger for use: 'Check it before a large batch.' This is clear contextual guidance, though it does not explicitly name alternatives or state when not to use the tool. The sibling list contains no overlapping read-only usage tool, so the guidance is sufficient.

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.