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

The description adds rich behavioral context beyond the readOnlyHint=enable annotation: explains caller-scoped server-side behavior, the union of token and member scopes, the re-minting implication on visibility, and the distinction between thread lifecycle state and delivery/read receipts. It also discloses the lack of delivery confirmation, which is critical for correct interpretation. No contradiction with annotations.

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 lengthy but every sentence earns its place: purpose, scoping nuance, limitations, return shape, and required scope. The most critical information (purpose and counterpart) is front-loaded. The density is justified by the tool's complexity, though slight trimming of the re-minting explanation might tighten it.

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 tool with no output schema, the description provides the return shape ({ok, count, threads}) and required scope (agent:inbox:read). It covers the important caveats (no receipt semantics, scoping subtleties) and gives a complete picture for an agent to invoke correctly. Given the complexity and lack of output schema, nothing essential is missing.

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% (both limit and offset have descriptions including defaults and max). The description repeats these defaults but adds no new semantic meaning beyond what the schema already provides. Baseline 3 is appropriate since the schema carries the full burden, and the description does not add extra parameter context like paging strategy beyond what's in the schema.

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?

States a specific verb and resource: 'Returns the threads the calling agent's token initiated' and explicitly distinguishes from the sibling ic_agent_inbox_list_threads (which lists threads addressed TO you). The sender-side counterpart framing makes its role unambiguous among many inbox tools.

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?

Provides explicit when-to-use guidance: 'Use this to follow up on requests/intros/messages you sent' and routes to ic_agent_inbox_get_thread for full thread details. It also clarifies what the tool does NOT tell you (no delivery/read receipts) and explains the scoping edge cases (re-minting, class-B clients), helping the agent decide when this tool is appropriate.

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