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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered; the description nonetheless reinforces it with "Sends nothing." It adds genuine behavioral detail the annotations cannot convey: the quote includes a 1% fee, price impact and minimum output, and partialFill/solCharged describe the curve-completion edge case. It stops short of describing the full response shape or staleness/liveness of the on-chain price.

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 sentences, front-loaded with what the tool produces and immediately followed by the non-mutating guarantee. Every clause adds information; there is no restatement of the name or title.

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 carries the burden of explaining returns, and it covers the key fields (fee, price impact, minimum output, partialFill, solCharged). It does not enumerate the remaining response fields or note whether the curve price is stale, but it is sufficient for an agent to call the tool correctly.

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%, including the lamport/token-unit distinction for amount and the default 300 bps for slippageBps, so the schema already carries parameter meaning. The description adds only trade-direction framing (buy vs sell) and nothing about slippage or mint semantics beyond that, matching the baseline-3 expectation when the schema does the heavy lifting.

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: pricing a buy or sell against the token's live on-chain bonding curve, with the 1% fee, price impact and minimum output called out. An agent can tell this computes a quote rather than executing anything. It does not name prepare_trade as the sibling it contrasts with, so sibling differentiation is left implicit.

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?

"Sends nothing" implies this is the pre-trade, quote-only step, which is useful usage context, and the partialFill note explains how to read the result. However, there is no explicit when-to-use vs prepare_trade guidance or stated prerequisite, so the agent must infer the relationship between pricing and preparing a trade.

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