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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds meaningful context beyond that — 'say once' signals a one-shot report consistent with idempotency, and 'for diagnosis' frames the intent — but it does not disclose whether the report is stored, what the caller should expect back, or any rate/one-call constraints.

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 very short sentences with no filler, so it is certainly concise. But brevity here tips into under-specification: the key scoping statement ('Not for conversation') is a fragment placed last, and the opening sentence is oblique about the actual action.

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 explained, and the annotations carry the safety profile. What is missing for an 11-parameter diagnostic tool is any account of what the diagnostic payload is for or how a caller should populate it, leaving the agent able to identify the tool's role but not to invoke it confidently.

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?

Eleven parameters with only 55% schema description coverage, and the description adds nothing about any of them — not the required 'app' and 'bridge' enums, not the diagnostic fields like trace/phase/frame. Since coverage falls below the 80% threshold, the description was expected to compensate for the undocumented parameters and does not.

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 conveys that this is a diagnostic channel through which in-chat cards report which host bridge they run in, and it distinguishes itself from the PDF-manipulation siblings by declaring it is 'not for conversation.' However, it never states a concrete verb for what the tool does with the report (records it? returns it? registers the card?), so the action itself remains vague.

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?

'For diagnosis. Not for conversation.' provides a rough when-to-use and when-not-to-use pair, which is more than most descriptions offer. But no alternative tool is named for conversational needs (e.g. ask_pdf), and no prerequisites or call conditions are given, so the routing guidance is implied rather than explicit.

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