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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description does add real context beyond them: records are tenant-bound (isolation), results reflect an exact content revision, public content matches are limited, and the warning "Unknown is not zero or verified coverage" tells the agent how to interpret empty values. It still says nothing about error behavior when the id is absent or unknown.

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 sentences, front-loaded with the verb, no filler or marketing language. The comma-separated attribute list is compact but reads as a run-on, and the final sentence is terse enough to be ambiguous about what exactly it is warning against.

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 no output schema and a 0%-documented single parameter, the description does roughly the right job by naming the categories of data returned and flagging unknown-versus-verified semantics. It remains incomplete on the id contract and on what a caller sees when the release does not exist or is outside the tenant.

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 0% for the single required parameter, so the description must carry meaning; "exact content revision" implies the id pins a specific immutable revision rather than a live record, which is genuinely useful semantics. It never explains the id format (the mcr_ SHA-256 shape only appears in the schema pattern) or what happens if a revision-specific id is stale.

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?

"Read one tenant-bound release" gives a verb and a resource with scope, and the rest of the sentence enumerates the data the read covers (revision, approval, pages, outreach, outcome evidence). But the enumeration is a dense noun pile that never says how this differs from prepare_press_release or get_press_workspace, so the agent must guess at the boundary.

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?

There is no when-to-use statement, no prerequisite, and no pointer to an alternative tool for adjacent needs (workspace overview, preparation). The closing caveat about unknown values is a data-semantics note, not usage guidance, leaving the agent to infer the trigger condition from the name alone.

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