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

With no annotations provided, the description carries full behavioral disclosure and does so richly. It enumerates the exact verification checks (network, USDC contract, recipient wallet, amount, confirmation status, tx_hash replay protection, sender match) and explicitly discloses the side effects on success: recording the donation, incrementing campaign funded_amount, and returning donation_id, status 'completed', and tx_hash.

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 compact: two sentences, front-loaded with the flow step and required inputs, then a dense list of verification checks and effects. Every sentence contributes operational value with no filler or redundancy.

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?

Given no annotations and no output schema, the description is substantial but still incomplete for correct invocation. It thoroughly covers success behavior and side effects, but omits failure behavior and leaves amount, reasoning, and tx_hash semantics underspecified, which an agent needs to call the tool 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?

Schema description coverage is only 25%, so the description must compensate, but it merely lists the required parameter names without explaining semantics. It does not define amount units, tx_hash format, or what content reasoning should contain. Only campaign_id receives meaningful guidance, and that comes from the schema rather than the tool description.

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 clearly identifies confirm_donation as 'Step 2 of the MCP donation flow' and states its core action: verifying an on-chain payment and recording the donation. It specifies the verification targets and the success return values, which distinguishes it from siblings like donate and get_campaign_donations.

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 gives clear context by framing the tool as 'Step 2' and requiring campaign_id, amount, reasoning, and tx_hash, implying use after an on-chain payment is made. The campaign_id schema note adds a specific when-not guidance about not sending a second donation after a transfer, but there is no explicit comparison to the donate sibling or fuller exclusions for failure cases.

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