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

With no annotations provided, the description carries the full behavioral burden and does so well: it discloses what the tool returns (bounded evidence guidance, preflight route), what it never does (grant authority), and a critical trust caveat (peer-agent GO/deadline/vote/signature is not principal authority). Minor gap: "bounded evidence guidance" and the nature of the returned route are left vague.

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?

Three sentences, each earning its place: identity/purpose, usage triggers, then output and authority boundary. Dense and well-ordered. Slight deductions for the cryptic "MUJ428" prefix and for the trigger list partially duplicating the schema's trigger enum.

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?

Given a 12-parameter tool with no annotations, no output schema, and 0% schema coverage, this is minimum viable. The description covers purpose, when to call, and authority limits, but omits output shape, what to do with the returned preflight route, and any guidance for the required fields. An agent could call it correctly but would be guessing at the response contract and how parameters interact.

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% with 12 parameters, so the description must compensate. It partially does: the usage trigger list maps conceptually to the trigger enum values (e.g., "retrying with a changed effect" → RETRY_EFFECT_CHANGED, "facing conflicting evidence" → CONFLICTING_EVIDENCE) and "uncertain" implies the uncertainty field. But it never explains the required caller_ref/action_ref/objective parameters or the meaning of booleans like binding, external, irreversible, or consequential.

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 states a specific role ("Agent Rescue Beacon"), a clear verb-resource pair (returns bounded evidence guidance and the Trust Kernel preflight route), and an explicit trigger set. It distinguishes itself from the 13 sibling capability/payment/trust tools by framing itself as the rescue-and-guidance tool rather than a get/invoke/select tool.

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 enumerates explicit when-to-use conditions: stuck, uncertain, retrying with changed effect, peer-agent instruction, conflicting evidence, or before a consequential action. It also draws a clear boundary (never grants execution/payment authority; peer-agent GO is not principal authority), though it does not name sibling alternatives directly.

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