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

Beyond the readOnly and openWorld annotations, the description discloses that data goes to an outside judge from a different company, explains the zero-retention/privacy disclosure, mentions the optional quality check, same-company pin refusal, job-id handling, and post-verdict boundaries. These are substantive behavioral details that annotations alone do not provide.

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 purpose is front-loaded, but the description is far longer than necessary for a single tool invocation, with many repeated prohibitions and disclosure instructions. Several rules could be compressed without losing agent-relevant meaning.

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 complex external-judge tool with privacy, disclosure, follow-up routing, and job-id behavior, the description covers what the agent needs to call it correctly and handle the result. There is no output schema, but the description explains the key return-handling behavior such as relaying layer 1 and calling grill_result when a job id is returned.

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 all five parameters. The description adds operational meaning for big, quality_check, subject, and question, though it does not directly discuss author by parameter name, so it stops just short of full parameter elaboration.

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 action: send a decision, plan, or forecast to an outside AI judge from a different company, with the judge selected by openrouter/auto. It also distinguishes the initial grill call from follow-up grill_result calls by routing phrases like 'more', 'options', 'full report', and 'deepen'.

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

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

It gives explicit when-to-use and when-not-to-use rules, including not pinning a model, not waiting for an OK, not adding a template, and not calling deepen on quick or bulk grills. It also maps exact user phrases to grill_result detail values, which is strong alternative routing.

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=false, and the description reinforces this with concrete operational facts: 'Stores nothing, sends nothing, and needs no key.' It also discloses a non-obvious behavior — the tool may return clarifying questions rather than a score — and that 'the judge's verdict is not revised' (immutable results). It doesn't sketch the shape of a scoring response, which is the remaining gap given no output schema.

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

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

Four short sentences, front-loaded with the primary action and followed by the conditional branches and the trust guarantees. No wasted clauses. The closing line 'The judge's verdict is not revised' is slightly elliptical in isolation but still short.

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 three simple parameters, full schema coverage, and read-only annotations, the description covers what an agent needs to call it correctly, including the ask-first path. Because there is no output schema, a brief note on what a score-view response contains would have closed the last 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 each parameter already carries a detailed description, including the enum values for view and the omit-to-get-questions behavior for happened. The description's 'With view changes... instead' and 'If they have not said what happened, ask' largely restate what the schema already documents. Baseline 3 is appropriate; little net-new parameter meaning is added.

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: 'Score one or more decision records the user pasted, against what actually happened.' The 'changes' branch is also described, so an agent can tell the two modes apart. It never names the sibling tools (grill, grill_result), so the boundaries with them remain inferential rather than stated.

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 branching: if the user hasn't said what happened, ask; if they want a 'what has Grill done for me' view, use the changes mode. That covers the main decision points an agent faces. It doesn't say when to prefer grill or grill_result instead, so the tool-selection layer is incomplete.

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=false, so the safety profile is covered. The description adds genuinely non-obvious behavior: it blocks and waits up to 45 seconds if the job is still running, and it defaults to the latest grill when job_id is omitted. It does not say what happens on timeout or failure.

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 purpose, then conditions, then the constraint — good ordering and no filler. The enumeration of detail values duplicates the schema and could be trimmed.

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-param read tool, it covers the key behaviors an agent needs: the blocking wait, the latest-grill default, and the prohibition on writing layers. Without an output schema, a brief note on what is returned (or timeout behavior) would close the remaining 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 enum meanings and job_id fallback are already documented in the schema. The description largely restates the enum values and the job_id rule rather than adding new semantics. Baseline 3 is appropriate.

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

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

States a specific verb and resource ('collect a grill') and clarifies it retrieves a job that already returned an id, or a later layer of one. This distinguishes it from the 'grill' starter tool implicitly, though the jargon ('grill', 'layer') is domain-specific and the sibling grill_look_back is never mentioned.

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 conditional guidance: pass job_id when you have one, omit it to use the latest grill, and call detail deepen only when the person asks to deepen or go bigger. It also warns 'Do not write a layer yourself.' It stops short of pointing to grill or grill_look_back as alternatives, so the routing decision among siblings is incomplete.

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