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

Annotations already establish the safe-read profile, and the description goes beyond them with real behavior: the result is either one ACM-68000 signal or an evidence_gaps list of pages checked, elements carry back-pointers to chapter/record fields, and output is signed (kid allooloo-eco-2026-10) and receipted at mcp.rco-records.ai. That is meaningful disclosure for a read tool, though the jargon reduces its practical value.

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?

It is a single unbroken sentence stitched together with colons and em-dashes, and roughly half its tokens are opaque codenames and identifiers. The resource is front-loaded, but the signing/receipt clause and nested parentheticals make it hard to scan rather than economical.

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 steps in to describe both return branches (signal vs evidence_gaps), provenance of elements, and the signing/receipt envelope — enough to interpret a response. It stops short of explaining failure modes or how to obtain valid client categories in practice, which is a real gap given the strict enum-like matching requirement.

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 100%, so the baseline is 3. The description does add one linkage not in the schema — that the subject's home market determines which chapter supplies the valid client_category — but it adds nothing about subject formats or how the chapter's category list is discovered.

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?

It names a specific resource ('AIO-10060 orderability outcome') and scope (one security + one client category of the home-market chapter), and ties itself to get_record's subject resolution. But the core nouns — 'AIO-10060', 'chapter', 'node', 'apex', 'door' — are undefined internal jargon, so an agent that hasn't been primed cannot tell what domain object is actually returned without guessing.

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?

There is no statement of when to call this instead of get_record or get_signal; the only sibling reference ('as for get_record') is an analogy about subject resolution, not a routing rule. The distinction from get_signal, which sounds closest in output shape, is never addressed.

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