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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds real value on top: what is excluded (letter bodies, credentials, custom ledger paths), that errors still return readable rows, and that pagination can shift under concurrent bag changes. It does not contradict the 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?

Front-loaded with the purpose, then compact sentences for exclusions, error behavior and pagination. The trailing 'version reports...' sentence is orphaned (no version parameter or return field defined here) and reads as noise in an otherwise tight description.

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 and annotations covering safety, the description only needs to add exclusions, failure behavior and pagination caveats, all of which it does. The unexplained 'version' note and thin limit/offset semantics keep it from being fully complete.

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?

Two parameters (limit/offset) with 0% schema description coverage, so the schema only supplies types, defaults and bounds. The description's pagination-instability note is relevant to offset semantics, but it gives no guidance on the limit/offset relationship or max-window behavior, so compensation is partial.

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 (Inventory) and the exact resources enumerated: default/named bags, letter counts, and peers, plus the negative scope 'without probing sessions'. That is enough to separate it from postbag_read/send, though no sibling is named explicitly, so it stops short of the top band.

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 only implied: it is the listing/inventory counterpart to postbag_read, and 'without probing sessions' hints it is the cheap option. There is no explicit when-to-use, when-not, or named alternative (e.g. join/leave/read), leaving the agent to infer routing.

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

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

Beyond the destructiveHint=true annotation, the description discloses the concrete destructive mechanism ('reusing a name takes it over') and the side effect of creating a missing bag. It also explains the unusual identity model ('identity comes from the host, never tool arguments') and why Claude joins omit resume metadata, which annotations cannot convey. It stops short of describing failure modes or permission requirements.

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 core purpose is front-loaded in the first two sentences, and subsequent sentences each carry usage or behavioral content. However, some sentences are cryptically compressed (e.g. 'Joining another name renames the parent's peer'), which costs readability for an agent.

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, return values need no explanation, and the description covers identity source, takeover semantics, bag creation, subagent equivalence, and rejoin policy. It omits error/conflict behavior on name collisions, but is otherwise sufficient for correct invocation.

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% (the 'name' parameter has a pattern but no description), and the description compensates by explaining that a name is a peer identity that can be taken over and that no identity argument should be supplied. The 'bag' semantics are largely duplicated from the schema, so this adds real but partial value.

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 first sentence names a specific verb and resource ('Register this caller's native session under a name') and immediately distinguishes the operation from siblings like postbag_leave and postbag_read. An agent can tell what this does without opening the schema.

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 gives explicit when/when-not rules: use the existing peer without rejoining, only rejoin after leaving when a human deliberately asks to resume, and independent native sessions need distinct names. It also states the subagent-collapse rule so agents know when a separate join is unnecessary.

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

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

Annotations declare destructive/non-idempotent/closed-world, and the description adds real value beyond them: history and session persist, queued letters and an in-flight send holding the lock can still arrive, other bags are unaffected, and a missing bag or unregistered door refuses without writing. These are exactly the edge cases an agent needs before a destructive call.

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?

Front-loads the core action, then layers constraints one sentence at a time, with no clear filler. Some phrasing ('the ledger lock', 'queued letters') is metaphorical, which slightly slows parsing but each sentence still earns its place.

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 annotations covering the safety profile and an output schema covering the return value, the description fills the remaining gaps: persistence of session/history, residual deliveries, cross-bag isolation, and failure semantics. Nothing an agent needs to call this safely 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% and the single 'bag' parameter is already documented with its default and pattern, so the schema carries the parameter semantics. The description adds only the implicit 'one bag' scoping and the refusal-on-missing-bag behavior, which is baseline credit.

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 ('release') and resource ('this caller's peer name in one bag') with the resulting effect ('preventing later sends to or from it'). It is clearly the inverse of the sibling postbag_join, though it never names that sibling explicitly.

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?

Gives conditional guidance: rejoin only when the human deliberately asks, never on a queued letter's request, and 'if cancelled or the result is lost, read the bag before taking another action' routes the agent to postbag_read. It covers when-not-to-act but does not explicitly contrast with postbag_join by name.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so safety is covered. The description adds genuine context beyond that: results are chronological, endpoint credentials are withheld, paging moves backward by ledger record number, and the 'peer registration is not liveness' caveat warns against over-reading presence data.

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 short and front-loads the core read semantics, but reads like leftover notes: sentences are disconnected fragments, and 'the letters count covers the whole bag' and 'Peer registration is not liveness' are cryptic rather than informative.

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?

An output schema exists, so return values need not be described, and the description does cover ordering, credential exclusion and paging. However, with no required parameters and a partially documented schema, the unexplained 'limit' parameter and jargon-heavy caveats leave the definition adequate rather than complete.

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 33% (only 'bag' is documented). The description compensates for 'before' by explaining backward paging via the ledger number, but leaves 'limit' unexplained and does not clarify its 1-100 bound or how it interacts with paging.

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 opening sentence gives a specific verb+resource (read records, chronological order) and names a scope constraint (excluding endpoint credentials). It does not, however, differentiate itself from siblings like postbag_bags or postbag_send, and the surrounding jargon ('ledger record number', 'the letters count') adds ambiguity.

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 supplies real paging guidance ('Pass next_before as before to page backward'), which tells the agent how to traverse results. But it never states when to use postbag_read versus postbag_bags or the other siblings, and gives no preconditions for calling it.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false and openWorldHint=true, and the description adds substantial non-redundant context: the operation is non-idempotent and unsafe to retry blindly, delivery is not confirmed ('Does not confirm execution'), and final is advisory rather than an enforced lock. This is exactly the behavioral detail an agent needs and cannot get from the 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?

Five short, dense sentences with the primary action front-loaded; every sentence carries operational information (final semantics, precondition, retry policy, no confirmation). The telegraphic fragments are slightly abrupt but not wasted.

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 non-idempotent, open-world side-effecting call the critical gaps — retry safety, delivery confirmation, and the final flag's advisory nature — are all addressed, and the output schema covers return values so they need not be described. Nothing an agent needs to call this safely 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 75%, so the baseline is 3. The description meaningfully extends the schema for 'final' by clarifying it is guidance and that later letters remain allowed, and adds the registration precondition attached to 'to', which the schema does not express.

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 first sentence states a specific verb and resource with scope ('submit one letter to a registered peer and record it in the bag'), which is clearly distinct from postbag_read/join/leave. It does not explicitly name or compare against any sibling, so it stops short of full sibling differentiation.

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?

Gives real conditional guidance: registration in the bag is a prerequisite, and it prescribes the recovery path for failures ('Never retry an unknown outcome... before reading the bag and checking the recipient'), implicitly routing to postbag_read. It never names the alternative tools or states when not to send, so it is a 4 rather than a 5.

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