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

Annotations already establish read-only, idempotent, closed-world, non-destructive behavior, and the description adds substantive context on top: what the ratio is compared against, that thresholds are sourced with links, that operational fixes are suggested, and two explicit disclaimers (no network-identification determination, not legal or financial advice). The credential-handling warning is a genuinely useful safety note that annotations do not cover.

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 trigger condition is front-loaded in the first clause, and every subsequent sentence carries distinct information: computation, comparison framing, threshold sourcing, fixes, and scope limits. It runs as one dense multi-clause sentence at the start, which slightly hurts scanability, but there is no filler.

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?

With an output schema present, the description need not explain return values, and it covers everything else an agent needs: invocation trigger, accepted input forms, analytical scope relative to Visa VAMP and Mastercard ECM, and explicit out-of-scope disclaimers. No prerequisite knowledge is left implicit.

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, but the description adds real meaning by framing the inputs as two alternative forms — either separate counts or a pasted free-text summary that may already be a percentage. That clarifies the relationship between the `summary` field and the numeric pair, which the schema lists only as an optional string.

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 definition names a concrete verb and resource — computes disputes divided by transactions — and enumerates the deliverables (VAMP/ECM comparison, threshold summary with source links, suggested operational fixes). Nothing in the sibling set (application checklists, policy readiness, processor fit) overlaps, so the agent can route confidently without opening the schema.

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 trigger is explicit: use when the merchant supplies a monthly transaction count and dispute count, or pastes a short summary of those figures. It also states a clear negative boundary — it does not determine whether a card network has identified the business — plus a data-handling exclusion about card numbers and credentials. No named alternative sibling is offered, which keeps it just below a 5.

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