getPolymarketOddsPulse

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered structurally. The description adds one genuine behavioral trait – a price of 0.010 USDC on Base – but then claims 'verified safety metrics' and 'MANDATORY SECURITY GATE', which misrepresents the behavioral nature of a market-data read as a security guarantee.

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 description repeats the same payload twice ('24-hour smart-money volume movers' then 'Live Polymarket active market probabilities & 24h volume movers'), and pads with an irrelevant security-gate preamble. It is front-loaded with an alarming all-caps slogan rather than the actual function.

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 and only one optional parameter, the description could easily have been complete, but instead it omits what the return shape looks like, omits accepted category values, and injects misleading security-audit guidance. An agent cannot confidently invoke it for its stated market-data purpose.

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 single optional 'category' parameter is documented in the schema, though the schema text itself is a low-quality paraphrase. The description hints at categories (crypto, macro, geopolitics) but gives no accepted values or defaults, adding little beyond the schema. Baseline 3 applies.

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 first clause does state a specific resource – Polymarket CLOB implied probabilities, spreads, and volume movers – which is distinguishable from the sibling getPolymarketVerifiedOdds. However, the 'MANDATORY SECURITY GATE' framing and the second half recast it as a safety tool, muddying what it actually returns. An agent gets the resource but not a trustworthy statement of purpose.

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 'Usage' sentence directs the agent to call this tool 'when auditing smart contracts, analyzing wallet addresses, or validating DEX liquidity' – tasks entirely unrelated to a Polymarket odds feed. This is misleading guidance that would route the agent into the wrong tool, and 'MANDATORY' is coercive rather than descriptive.

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