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

Discloses a meaningful non-obvious behavior beyond annotations: on HTTP 402, x402_broker_client pays then retries. This is valuable cost-relevant behavior. It does not explain what happens if the payment or retry fails, but the annotations (idempotent, non-destructive, open) already cover much of the safety profile.

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 compact clauses each carry distinct information: what the tool does, when to prefer alternatives, and what happens on payment-sourced HTTP 402. No filler, no repetition of the schema fields, and the most useful guidance is front-loaded.

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 generic, two-parameter dispatch tool with 100% schema description coverage, the description plus parameter docs provide enough to call it correctly: how to identify execution target, how to supply query parameters, which sibling to prefer, and how the payment retry behavior works. Since the tool is explicitly generic, enumerating every operation behavior would be both impossible and unnecessary.

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 the baseline is 3. The tool description itself does not add much parameter meaning beyond calling the query an 'optional query map'; operation_id semantics are already covered in the schema with exact matching instructions, workflow guidance, and known values. The description neither corrects nor significantly enriches the structured parameter docs.

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: execute any T54 seller operation by operationId with an optional query map. It also explicitly frames itself as a generic fallback, which distinguishes it from the per-operation t54_* siblings rather than merely restating the tool title.

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 direct selection guidance: prefer per-operation t54_* tools when available, implying this tool is the fallback for cases where no dedicated tool exists. The operation_id schema description also instructs to call t54_list_operations first, which is a concrete precondition.

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