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

With no annotations, the description carries the full burden of behavioral disclosure and does so thoroughly: it always returns a denial, ignores all arguments, and provides an incident reference. This goes beyond the schema and prepares the agent for the exact error response.

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 structured with the intended purpose first, followed by the disabled status, rationale, and return behavior. Every sentence adds necessary information, though the incident details add some length. Overall, it is focused and scannable.

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?

For a disabled tool, the description is complete: it explains the behavior, the denial error, and that arguments are ignored. With no active functionality and an output schema present, there is no further information an agent needs to call or avoid calling it correctly.

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%, but the description compensates by stating 'All arguments are accepted for schema stability and are ignored.' This tells the agent that count, agent_id, and pioneer_key have no effect, which is the essential parameter information for a disabled tool.

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 clear verb and resource: 'Read the most recent coordination handoff record(s).' This distinguishes it from siblings like coordination_handoff_create and coordination_team_status. The disabled status does not obscure the intended purpose; it explicitly states what the tool does and its current unavailability.

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 explicitly states the tool is 'closed to every caller' and always returns a denial, providing a clear when-not to use it. It does not name alternative tools, but the exclusion is unambiguous for a disabled tool. A 5 would require explicit alternatives.

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