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

With no annotations, the description carries the full burden and does well on outputs: it discloses per-pool risk scoring, venue-level 24h liquidity-loss history, and that the data is unvetted/spam-prone. It also states the payment requirement ('Costs $0.01 USDC on Base via x402'), which is genuinely useful since the existing sibling list includes x402_market_summary etc. It still omits operational behavior: latency/freshness of 'first sight', pagination limits beyond the max 50, and what happens when the window exceeds the block cap.

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?

Purpose is front-loaded and every clause carries real information (venues, token fields, hooks, pairing, liquidity, risk score, venue loss stats, payment). But the middle is one long run-on enumeration strung together with commas and semicolons, which makes it harder to parse than it needs to be; a short field list would read faster.

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?

For a fairly complex multi-venue feed with no output schema and no annotations, the description is nearly complete: it enumerates the returned fields, flags data quality, and discloses the paid x402 access model. The remaining gaps (ordering guarantee, whether the 50-pool cap means repeated calls, freshness of first-sight timestamps) are secondary.

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% and both parameters already document ranges and defaults (limit 1-50 default 25; minutes 5-240 default 60). The description only adds that the window is expressed in minutes and that results are the newest, so it does not meaningfully extend parameter meaning. It also inherits an oddity from the schema: the minutes cap is explained in terms of 'about 50 minutes on Arbitrum' on a Base-only tool.

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 opens with a specific verb+resource ('New trading pools created on Base in the last N minutes') and names the exact venues covered (Uniswap v4/v2/v3, Aerodrome), which cleanly separates it from chain-sibling feeds like eth_new_pools, arbitrum_new_pools and from non-pool tools such as base_token_snapshot or base_large_trades.

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?

Usage is implied by the 'last N minutes' framing and the explicit warning 'Unvetted: many new pools are spam', which tells the agent this is a discovery/early-signal feed rather than a safety-verified source. However, there is no explicit when-to-use/when-not guidance and no routing to alternatives such as token_risk_check or token_verdict for follow-up verification.

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