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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely beyond that: status remains observable after deletion or expiry, and the lease bearer must be supplied on the transport, never as a tool argument. That credential-placement rule is non-obvious behavioral context an agent could otherwise get wrong.

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 dense sentences, front-loaded with what is returned and followed by the one operational constraint that matters. Nothing is padded, though the second sentence could have been phrased more compactly.

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 an output schema present, the description needn't restate return shapes, and it covers the remaining gaps well: lifetime behavior (terminal status), authentication mechanics, and what the call is scoped to. An agent has everything needed to invoke this one-parameter read 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?

There is one parameter with 0% schema description coverage, so the description carries the burden. It only says 'for one inbox' and rules out adding the bearer as an argument; it never explains the inbox_id identifier format, provenance, or how it is obtained relative to the random receive-only address it returns.

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 names a specific verb and resource ('Return ... authoritative lease status ... for one inbox') and enumerates the returned fields (receive-only address, lease status, expiry). It implicitly separates this from siblings like ausca_agent_inbox_delete or ausca_extend_inbox, but never names an alternative, so it stops short of a 5.

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?

Usage is implied rather than stated: the mention of 'terminal status after deletion or expiry' hints this is called after destructive lifecycle events, and the transport note tells the agent where to put the bearer. No explicit when-to-use or when-not-to-use versus the other inbox tools is given.

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