Look back at a decision record

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.