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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false. The description adds meaningful context beyond those: it is free, triggers no new calculation or fresh observation, and only 'ready' operations expose certain captured data, which is a state-dependent behavioral trait.

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 purpose and then adds scoping details. It is reasonably sized, though the second sentence's list of exposed data ('identity observations, complete comparison indexes, labelled facts, original-reading actions') is dense and somewhat jargon-heavy for a status tool whose return shape is already captured by an output 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?

Given a simple read-only tool with one parameter, an output schema, and rich annotations, the description covers purpose, cost, and state-dependent output. The main gap is the absence of parameter semantics for operation_id, but otherwise it provides enough context for correct invocation.

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 0% for the single required parameter, operation_id, and the description does not explain its origin, format, or how to obtain it. It only implies ownership via 'owned operation's state,' which adds minimal meaning beyond the parameter name and pattern in 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?

States a specific verb ('Read') and resource ('owned operation's state and accounting'), making the core purpose clear. However, it uses 'operation' while siblings use 'research_request' (e.g., list_research_requests, cancel_research_request), so it does not explicitly differentiate itself from those alternatives.

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 implies usage by saying it reads an owned operation's state and is 'Free; no new calculation or fresh observation,' which suggests it is a cheap status-check tool. But it names no alternatives, no when-not conditions, and no prerequisites for obtaining the operation_id.

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