Agent Data API

polygon_new_pools

New trading pools created on Polygon PoS in the last N minutes on Uniswap v4, Uniswap v2, Uniswap v3: both tokens with symbol, name and decimals, fee tier, v4 hooks, whether it pairs with POL, WPOL or USDC, and quote liquidity where readable; plus, from our launch history, each pool's first-sight risk score and how many new pools on its venue lost their liquidity within 24 h. Unvetted: many new pools are spam. Costs $0.01 USDC on Base via x402.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "polygon_new_pools"
  }
}

Input Schema

Name	Required	Description	Default
`limit`	No	Max pools listed, newest first, 1 to 50, default 25
`minutes`	No	Look-back window in minutes; 5 to 240, default 60 (capped at 12,000 blocks, about 50 minutes on Arbitrum)

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 24, 2026

TDQS

A3.6/5.0

Behavior3/5

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

No annotations are supplied, so the description carries the full behavioral burden. It does well on several fronts: it flags the unvetted/spam nature, discloses a per-call price ($0.01 USDC on Base via x402), and honestly hedges data reliability ('quote liquidity where readable') and the provenance of the risk score (derived from launch history). It says nothing, though, about ordering beyond the schema, empty-result behavior, or what a missing risk score means.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is one dense semicolon-chained sentence that packs return fields, risk-score provenance, a spam warning, and pricing into a single block. The chain/venue/time scope is correctly front-loaded, but the run-on structure makes the payoff fields and the caution harder to scan than separate sentences would.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description compensates by enumerating the returned fields (both tokens' symbol/name/decimals, fee tier, v4 hooks, quote asset, liquidity, risk score, venue 24h liquidity-loss rate) plus cost and trust caveats. That is close to a prose output schema; only interpretation guidance for the risk score and the 'where readable' conditions is left implicit.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%: both `limit` and `minutes` document ranges and defaults themselves. The description adds only the framing 'in the last N minutes', which restates the `minutes` semantics without adding encoding or edge-case detail, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('New trading pools created'), pins the chain (Polygon PoS), the time window, and the three venues (Uniswap v4, v2, v3), then enumerates the returned fields. This clearly separates it from eth_new_pools, base_new_pools and the other chain-scoped siblings without needing the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The 'Unvetted: many new pools are spam' note implies this is a discovery/screening tool rather than a due-diligence source, but there is no explicit when-to-use, no pointer to token_risk_check, polygon_token_snapshot, or polygon_large_trades as follow-ups, and no guidance on choosing window sizes. Usage is inferable but not directed.

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

All Agent Data API tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?