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

Annotations only mark the operation as mutating and not destructive, so the description carries real behavioral weight. It discloses the important one-endorsement-per-identity rule, that re-endorsing replaces previous terms, and that omitted fields revert to defaults; it also notes the operation is free.

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 use case is front-loaded in the first sentence, and the remaining sentences deliver behavioral constraints, endpoint/signing info, and body field guidance without filler. The one-word 'Free.' is purposeful, and the body-field list is compact and actionable.

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 behavior, replacement semantics, body contents, and the signing target. However, there is no output schema and the description does not mention what a successful endorsement returns or how failures surface, and the budget fields lack value/unit guidance. For a 7-parameter signed mutation, this is adequate but not 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?

Schema coverage is high and top-level parameters are already well described, so the baseline is 3. The description earns extra credit by enumerating the required and optional inner JSON fields — price_ceiling_per_call, expected_volume, total_budget_cap, plus notes, callback_url, and expires_at — which the opaque body string alone would not reveal.

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 opens with 'Stack your own budget onto a wish someone else posted,' giving a specific action, object, and ownership scope. It also names the REST target 'POST /wishes/{wish_id}/endorse' and, by emphasizing 'someone else posted,' clearly differentiates this from sibling submit_wish.

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 explicitly frames the tool for existing wishes posted by another identity, which tells an agent the key precondition for using it. It does not name sibling alternatives or state explicit 'don't use' rules, but the context is clear and not misleading.

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