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

Annotations already declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false, so safety is largely covered. The description adds genuinely non-obvious behavior: this is a request for display rather than a synchronous render, and confirmation of a pending presentation must be read back via get_context. That async-confirmation pattern is not derivable from the annotations or 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?

Two compact sentences with no filler; the action and its trigger come first. The trailing get_context sentence is really usage/verification guidance, but it is short and useful enough to keep.

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?

An output schema exists, so return values need not be described, and the annotations plus schema cover safety and parameter contracts. The remaining gap is what happens when a display request is not confirmed or cannot be shown, which the description leaves entirely to get_context to reveal.

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 operation_id retry/replay semantics, capability privacy, and context_handle meaning are all documented in the schema itself. The description adds no parameter-level meaning beyond that, so the 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 verb (reveal/display) and resource (an inspected passage or difference), which distinguishes it from generic readers like read_context or get_outline. The phrase 'inspected passage' is domain jargon that assumes prior context, but combined with the title it is unambiguous about the action taken.

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?

Supplies a trigger condition ('when the person needs to see it') and points at get_context as the follow-up whose report tells you whether the presentation was confirmed. It does not, however, contrast with adjacent siblings such as show_changes, inspect_visual, or draw, so the agent must infer which display tool fits which situation.

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