agent_message_get

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

The description itself is behaviorally rich: it discloses the 7-day pruning window, the fact that a pruned-id lookup reports pruning rather than a missing record, and the delivery-state fields returned (delivery_status, delivery_method, socket_attempt_at, confirmed_at, fallback_claimed_at, typed_at, delivery_note). However, it frames the operation purely as 'Read' while annotations set readOnlyHint=false, so the description and the structured safety signal disagree about whether this call mutates anything. Per the rubric this contradiction caps the score; the compensation is that the remaining behavioral content is well above average.

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 and the id source are front-loaded in the first clause, and every sentence carries non-redundant information (storage trigger, alternative path, pruning, error semantics, returned state). It is dense and the parenthetical field list makes the middle sentence run long, but there is no filler to cut.

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, the description carries the return-value burden and largely meets it by naming the delivery-state fields, and it also covers the error path for pruned ids. Given the tool's complexity, an agent has enough to call it correctly. What is missing is any statement about the message body's own format and whether the read itself affects delivery state (relevant given readOnlyHint=false).

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 50%: project_id is documented in the schema, message_id is not. The description compensates for the undocumented parameter by explaining exactly where the id comes from — a '[hive:worker NAME] [message #N ...]' pointer line — which the schema's bare 'integer, exclusiveMinimum 0' does not convey. project_id's meaning and scoping rule are already handled by the schema text, so nothing is lost there.

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 gives a specific verb and resource ('Read one agent-to-lead message in full') plus the selection key (the id from a '[hive:worker NAME] [message #N ...]' pointer line). It is clearly not the same thing as question_get or agent_output, though it never names a sibling explicitly. The scope is unambiguous, which is what matters for an agent deciding whether to call it.

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?

It states the exact conditions under which a readable message exists (a send over 300 characters from a non-lead to a lead, or any worker send to a Claude lead while quiet_messaging is on) and explicitly states the negative case: 'Every other send is typed with its sender tag and stores nothing, so there is no id to read.' That is strong when/when-not guidance; it simply stops short of naming an alternative tool for those other sends.

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