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

Annotations are thin (readOnlyHint=false, destructiveHint=false, openWorldHint=true, idempotentHint=false), so the description carries real weight and delivers: an unsigned call returns the live x402 PAYMENT-REQUIRED challenge (USDC on Base) and never auto-spends; retry only with a challenge-specific signature; missing chain/spot/OI yields a not-available result with nothing charged; a supplied signature authorizes one paid, irreversible settlement. These are exactly the cost/side-effect facts an agent needs before calling.

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?

Front-loaded with the core capability, then payment mechanics, then the not-available case and a disclaimer. Dense but nearly every sentence carries a distinct fact; the risk is mild over-length rather than waste, and the disclaimer line is arguably marginal but defensible for a paid financial tool.

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?

Given a 2-parameter schema, an existing output schema, and sparse annotations, the description covers the remaining unknowns: what is returned, the x402 payment lifecycle, failure behavior, and settlement irreversibility. An agent can decide to call, understand cost, and know how to retry without consulting anything else.

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 baseline is 3, but the description adds meaning the schema does not: payment_signature must be bound to the exact challenge, using it triggers a single irreversible settlement, and only a challenge-specific signature should be retried. The symbol parameter is left to the schema, which documents it adequately.

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: fetch dealer gamma-exposure and pin-risk map for one US ticker from live Tradier option chains, then enumerates the concrete outputs (long/short gamma regime, zero-gamma flip line, call/put walls, max-OI pin strike, per-strike GEX ladder). This is clearly distinguishable from siblings like ticker_dossier or aftersearch_quote, which do not deal with dealer positioning.

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 a clear trigger ('when an agent needs to know where options dealers are forced to hedge, e.g. before judging whether a move is dampened or amplified') and a concrete scenario ('check SPY's zero-gamma line before the open'). It also encodes the retry rule for unpaid calls. It stops short of naming an alternative sibling or stating when NOT to use it, so it is strong context rather than explicit routing.

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