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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description is not needed for safety. It adds real context beyond the annotations: the hard precondition the caller must supply, the false-arbitrage consequence of violating it, and the payment model (USDC on Base). It stops short of describing rate limits or latency, but the added behavioral detail is substantive.

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 sentences, front-loaded with the core operation and the equivalence precondition before the parameter recap. Dense but every clause carries a constraint or caveat; the final 'Not investment advice. Paid in USDC on Base.' lines are short and earn their place as disclosures.

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 returns, and annotations plus 100% schema coverage handle safety and parameter detail. The description supplies the remaining critical context: the user-confirmed precondition, the false-positive failure mode, and the acceptable input forms for a 4-parameter tool.

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 schema already documents strikes ordering, outcomes default, and the token_ids/market_slugs alternative. The description restates length/order alignment and mutual exclusivity but adds no syntax or format detail beyond the schema. Baseline 3 is correct 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: a monotonicity check across a set of Polymarket markets, with the pricing rule (higher strike must not be priced above a lower strike) spelled out inline. This is distinguishable from siblings like prediction.neg_risk_arbitrage or prediction.hip4_mispricing without opening any 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?

Explicitly scopes when the tool applies (markets YOU have already confirmed share the same underlying asset and expiry/resolution date) and states the negative case: it does NOT verify settlement-condition equivalence and unrelated inputs yield a meaningless or false signal. That is a clear when/when-not with a named failure mode.

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