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

Although readOnlyHint is already true, the description adds materially beyond annotations: the tool is 'free and uncapped,' it returns per-destination receipts plus a single pipeline status, and it explains the forward-only status-ownership model where one destination's later failure cannot demote another destination's ready_to_publish state. This is non-obvious behavioral context that prevents misinterpretation.

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 dense but every sentence earns its place: the first sentence defines the resource and output shape, the second gives usage priority, the third explains the format parameter, and the fourth clarifies the ownership model. The most important scoping constraint is front-loaded without burying the key 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?

There is no output schema, so the description must explain the return shape, and it does: pipeline status, per-destination format, stored draft, gate receipt, verdict, per-check detail, and thresholds. Combined with the clear parameter guidance and the readOnlyHint annotation, nothing an agent needs to select and invoke this tool correctly is missing.

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 only 33%, so the description carries meaningful weight for parameters. It clearly explains format's semantics (include draft text vs. overview-only) and ties suggestionId to 'an article suggestion,' which is inferable but not explicitly spelled out. The context parameter is already described in the schema, so the description adequately compensates overall.

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 opens with a specific verb and resource: 'Re-read an article suggestion's verification state without re-linting.' It clearly differentiates itself from lint_draft by emphasizing it recovers a known verdict rather than performing a fresh lint, so an agent can immediately identify what this tool does and does not do.

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 is explicit about when to use this tool: 'always use this instead of lint_draft to recover a known verdict.' It also gives concrete decision guidance for the format parameter—pass it to include stored draft text, omit it for the overview—which tells the agent exactly how to tailor the call to the operator's goal.

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