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

The description discloses far more than the annotations alone: the x402 payment requirement, the free price-probe call, the signed payment in _meta['x402/payment'], the receipt in _meta['x402/payment-response'], 3-day retention, no-account/no-API-key operation, and the structural refusal of unverified done entries. This is exactly the behavioral context an agent needs.

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 dense and front-loaded with the 'PAID' warning, but it is a long paragraph that mixes core call mechanics with feedback-channel details such as 'Every report is read and analysed daily; there is no individual reply.' Useful information, but it could be trimmed or structured into sections.

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?

The description covers the payment flow, receipt location, readback symmetry, retention, account-free access, error behavior, and the four-section briefing structure. With no output schema, this fully equips an agent to call the tool in either the price-probe or paid-submission mode.

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 100% and the schema already defines each parameter, including confidence/evidence rules and the measured/unverified constraint. The description repeats the handoff framing and the 'structurally forbidden' rule, but adds little parameter-specific meaning beyond what the schema already states.

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: deposit a typed briefing for the successor process, organized into DONE, NOT DONE, IN FLIGHT, and PICK UP FIRST. It also differentiates itself from handoff_read, which is the free read-back counterpart, so an agent can distinguish the tool from its sibling.

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 concrete usage context: deposit for handoff, successor reads via handoff_read, and use POST /feedback for complaints and questions. It also explains the two-call paid flow (price probe first, then signed payment). It does not state explicit 'when not to use' exclusions, but the alternatives are clearly named.

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