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

Annotations already cover the safety profile (readOnlyHint=true), and "Read-only" merely repeats them, but the description adds genuinely useful behavior: conditional disclosure when a credential may not read logs (`{withheld, required, hint}`), truncation to "up to 8 file:line rows", and a defined "unknown" state for the conflict probe. What it does not cover is cost/latency of a fan-out aggregation or error conditions for a nonexistent PR or repo.

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 purpose is front-loaded in the first clause, and most content earns its place given there is no output schema. However, the entire body is one 130+ word sentence with nested parentheticals and inline backticked field names, which reads as a wall of text; a short lead plus a field list would be far easier to parse.

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 read-only aggregate purpose, the description takes on the return-shape documentation and does so thoroughly, including the semantic meaning of each section and the special withheld/unknown cases. It is nearly complete for an agent to call it correctly, missing only error behavior and any hint on the scope or expense of the aggregation.

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%, so the description would ideally clarify the three parameters, but it says nothing about owner, repo, or number. The names are largely self-explanatory, yet the description never confirms that `number` is the pull request number (not an issue number) or the expected owner/repo format, leaving the burden entirely on the caller.

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?

"Compute a one-shot status summary for a PR" gives a specific verb and resource, and the enumerated contents (CI state, merge probe, conflictRisk, auto-merge, merge train) implicitly differentiate it from narrow siblings like get_pr_checks or list_pr_conflicts. It stops short of naming those siblings or stating explicitly that this is the consolidated alternative to calling them separately.

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 phrase "one-shot" hints that this is the single call to prefer over several narrower reads, which is a real but weak usage signal. There is no explicit when-to-use, when-not-to-use, or named alternative among the many PR-related siblings, so the agent must infer the routing itself.

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