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

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false; the description adds real value beyond them by disclosing the actual side effects — the deal is booked into the ledger and consumes the agent's cap, while no money moves. It does not cover edge behavior such as what happens if the deal is already approved or whether approval can be reversed.

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?

Three short clauses totaling roughly 25 words, with the prerequisite front-loaded in parentheses and the effect stated immediately after the verb. Nothing is padded and every clause carries information the agent needs.

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 two-parameter mutation with annotations and no output schema, the description covers prerequisite, effect, and authorization condition, which is enough to call it correctly. The remaining gap is failure/idempotency behavior on an already-booked deal, which matters given the ledger and cap side effects.

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 both parameters are already documented, and the description's note about workspace_key largely repeats the schema and the prerequisite framing. The only added nuance is that the deal must be 'pending', which implicitly constrains deal_id, so the baseline 3 applies.

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 and resource ('Approve a pending deal') and adds a clarifying consequence clause: it books the deal in the ledger and the agent's cap but 'pays nothing', which separates it from payment/commission tools. It stops short of naming which sibling to use instead of approving, so it is clear but not fully differentiated.

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 an explicit gating condition ('Only when the owner asked') and a prerequisite ('Needs the workspace_key from create_workspace'), which tells the agent both when and how it becomes callable. It does not name an alternative action for the case where the owner has not asked, leaving that inference to the agent.

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