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

Beyond the annotations, the description discloses material behavior: SwapEazi does not hold or move money, quotes are read at a date and not locked, and a human approval step is required downstream. It also explains how the winning route is chosen (lowest total the payer sends) and distinguishes measured versus "Being measured" figures. It does not address whether repeat calls create duplicate intents, which matters given idempotentHint=false.

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?

It is short and the core flow is up front, but the telegraphic sentence fragments ("Keyed.", capitalized "Being measured") hurt readability and the payoff sentence about not moving money and human approval, while valuable, reads as an afterthought.

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 no output schema, the description does well to sketch the response shape (routes plus a selected lower-total route) for a fairly complex seven-parameter tool. It stops short of explaining error/precondition behavior, duplicate-call semantics, or what the approval path looks like, which an agent would need to complete the task end to end.

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 100%, so the schema already documents all seven parameters, making the baseline 3. The description reinforces the key ones (payee, corridor, amount the payee must receive, deadline) and explains why customer_id matters via the negotiated-rate-on-record mention, but it adds no format or constraint detail beyond the schema and never mentions access_key.

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 says a business states payee, corridor, amount-to-receive and deadline, and that it returns route proposals with one selected. That is a recognizable purpose, but the leading fragment "Keyed." does not identify the operation as creating/registering a payment intent, and the route-proposal output overlaps with siblings such as price_routes, route_intent and recommend_payment_route with no differentiation.

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?

There is no explicit when-to-use or when-not-to-use guidance relative to the many pricing, routing and payment-preparation siblings. The clause "A person still approves" hints at an approval flow but does not say to follow up with request_payment_approval or approve_payment_run, so the agent must infer ordering.

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