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

The description states that a pledge is 'recorded on the packet's public backer ledger,' which is a persistent state change, yet the annotations set readOnlyHint=true. This directly contradicts the annotation's implication that no state is mutated. The description even says 'NO money moves' and 'none of it is ever held by Vealth,' which might be read as no financial state change, but the public ledger entry is still a write. Per the rule, any contradiction with annotations results in a score of 1, regardless of the otherwise rich behavioral detail.

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 a single dense paragraph, but every sentence serves a purpose: definition, non-custodial nature, balance-check behavior, distinction from payment, when to use, constraint, return values, signing method, and expiration. The most critical distinction (not a payment) is front-loaded. There is no filler or redundancy; the length is justified by the 2-step ceremony and signing requirements.

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 in a large family of prepare_* and submit_* siblings, this description is exceptionally complete. It explains the return values (MESSAGE_TO_SIGN and BODY_JSON), the exact signing method (personal_sign, not a transaction – no gas), the 5-minute window, and the follow-up tool (submit_backing). The output schema covers the raw structure, so the description need not repeat that. The only missing piece might be what BODY_JSON contains, but that is presumably in the output schema. This is a model of contextual completeness.

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%, so baseline is 3. The description adds extra meaning beyond the schema: it clarifies that amountUsd 'cannot exceed the packet's posted wage,' that backerWallet 'must hold at least amountUsd for it to verify,' and that the backer wallet signs with personal_sign (a plain message, not a transaction). It also mentions the optional reason is shown on the public ledger. This added context compensates beyond the schema, earning a 4.

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 states a specific verb ('Pledge to back a packet') and resource, then goes further to differentiate itself from prepare_funding by explaining that a pledge is NOT a payment and never marks the packet funded. It clearly separates the two-step flow (prepare_backing → submit_backing) and names sibling prepare_funding as the alternative for real payments. This gives an agent a precise understanding of what this tool does and what it does not do.

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?

Explicitly identifies when to use this tool: 'Use this when you want to signal real backing without paying yet, or when you want the demand recorded even though you cannot pay onchain right now.' It also contrasts with prepare_funding ('only a real settled payment through prepare_funding does that') and provides the next step (submit_backing within 5 minutes). This is textbook usage guidance with clear alternatives and conditions.

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