Provides live DEX market data on BNB Chain, including token prices, liquidity depth, pool reserves, best execution venue, liquidity risk, and pre-trade slippage estimation.
Provides live DEX market data on Polygon, including token prices, liquidity depth, pool reserves, best execution venue, liquidity risk, and pre-trade slippage estimation.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@dex-data What's the current price of ETH on Arbitrum?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Twenty-three tools for your agent — DEX market data, everyday utilities and reference data. Twenty-two need no API key, no wallet and no signup; one is paid and pays from a wallet you control.
claude mcp add dex-data -- npx -y dex-data-mcpThat is the whole install. Ask your agent "what's the price of WBNB on BSC?" and it answers from live on-chain pool state:
{
"symbol": "WBNB", "priceUsd": 677.25, "network": "bsc",
"via": "WBNB/USDT", "venues": 7, "totalTvlUsd": 117110555.6,
"confidence": "HIGH", "spreadBps": 25.26, "blockNumber": 117223818
}Measured 2026-08-21: all 22 free tools answered keyless, with full payloads. No tool is degraded on the free tier, and none returns a stub or a placeholder — the free answer is the same answer. What the free tier limits is how many calls per day, not what is in them.
Since 1.6.0 there is also one paid tool, get_dex_spread — see
Paid tools. It is the only tool that needs a wallet, it is labelled
PAID in its own description, and without a wallet it explains what to set and
spends nothing. The 22 tools above are unaffected by it.
Twenty-two free tools, no API key and no wallet, in three groups:
Multi-chain DEX market data — token prices, liquidity depth, pool reserves, best execution venue, liquidity risk, pre-trade slippage and gas costs across BNB Chain, Polygon, Arbitrum, Base, Avalanche and Optimism.
General-purpose agent utilities — geocoding, reverse geocoding, weather, web search, article/PDF to Markdown, and cryptographic randomness.
Reference and research data — search autocomplete, public holidays and business days, RSS/Atom feeds, IP geolocation, GLEIF legal-entity lookup and the US Treasury yield curve.
Related MCP server: AgentData MCP Server
The ledger says it plainly. Of 20,392 paywall challenges recorded, zero were genuine third-party queries — 82.5% were our own monitoring, 17.3% were catalogue crawlers walking every route with no parameters. We were being indexed, not shopped.
Bazaar listings are a bet on demand that does not exist yet. MCP is where agents already are today: Claude Desktop, Claude Code, Cursor, and every other MCP host. This server is the same data, delivered where the users are, and it needs no payment at all for the free tier — which removes the one barrier that a browsing agent cannot cross on its own.
Claude Code
claude mcp add dex-data -- npx -y dex-data-mcpClaude Desktop / Cursor — add to claude_desktop_config.json:
{
"mcpServers": {
"dex-data": {
"command": "npx",
"args": ["-y", "dex-data-mcp"]
}
}
}No API key, no wallet, no signup. The free tier answers every tool for a daily allowance; after that the endpoints fall back to x402 micropayments.
DEX market data
tool | answers |
| USD price of any ERC-20, by ticker or contract address |
| market depth and TVL per venue for a pair |
| which DEX is cheapest to buy on / best to sell into |
| price impact for a specific trade size |
| DEEP / MODERATE / SHALLOW / VERY_THIN depth class |
| gas cost in USD per chain, ranked cheapest-first (gwei is not comparable across chains) |
| raw reserves, fee and TVL per venue at one block — the data the others compute from |
| cross-venue arbitrage now, ranked by gross USD at the optimal size, not raw spread |
| supported chains and indexed tokens |
General-purpose agent utilities
Not a change of theme — these were chosen the same way everything else here was. Reading USDC receipts across 1,062 x402 seller wallets on Base ranked what actually gets paid for, and DEX data was not near the top of that list. Forward geocoding was (56 paying wallets), then weather, then article-to-Markdown, then randomness. These are the answers to that data.
tool | answers |
| address or place name to coordinates, worldwide (OpenStreetMap) |
| coordinates to the nearest street address |
| current conditions plus up to a 7-day forecast for any coordinates |
| free-text web search to ranked organic results, sponsored rows excluded |
| a public article or PDF URL to clean Markdown |
| CSPRNG integers or bytes, for agents that cannot generate their own |
Reference and research data
Chosen the same way, but from a corrected reading. The category totals in the original scan were double-counted — the biggest x402 sellers carry 10-16 of the 16 category tags each, so every category reported nearly the whole market's revenue. Seller-level rows are clean, and every tool below is something a wallet took real USDC for during the sampled window.
tool | answers |
| what people actually type about a topic — autocomplete, expanded into questions and comparisons |
| public and bank holidays for 100+ countries, and whether a given date is a business day |
| any RSS, Atom or RDF feed as clean JSON, summaries in both HTML and plain text |
| where an IP is, with the datacentre/VPN flag that says whether to believe it |
| a company's Legal Entity Identifier by name, with lapsed registrations flagged not hidden |
| the US par yield curve plus 2s10s / 3m10y / 5s30s and the inversion flag |
Local
tool | answers |
| what this session has spent on paid calls, and the caps in force |
Paid — needs a wallet you control
tool | answers | price |
| real-time cross-DEX price & spread on BSC: per-venue prices across PancakeSwap v2, PancakeSwap v3 (all fee tiers), Biswap and ApeSwap in one call, plus best buy/sell venue, gross arbitrage spread (bps + USD), optimal trade size, liquidity and block number | $0.01 USDC/call, no free tier |
This tool used to be a separate package, bsc-dex-spread-mcp. It lives here now:
one install, one config, free tools and paid tools side by side. Nothing else
changed — same route, same data, same price.
Before you reach for it, the free tools may already answer you.
get_liquidity gives per-venue depth for a pair and find_arbitrage gives a
cross-venue spread scan, both inside the 25-calls-a-day free tier with no wallet
at all. get_dex_spread is worth paying for when you want all four BSC venues
and the optimal trade size in a single call, or when you have exhausted the free
allowance.
Pairings worth knowing: geocode then get_weather turns a place name into a
forecast, search then url_to_markdown turns a question into readable source
text, and read_feed then url_to_markdown turns a feed into full articles.
Every one of the 22 free tools answers within a daily per-caller allowance — no
wallet, no signup. The remaining quota is returned on X-FreeTier-Remaining.
Beyond it, calls fall back to x402 micropayments (USDC on Base). get_dex_spread
is the exception: it is paid from the first call and has no allowance.
Every response carries the liquidity backing the number and a confidence rating. A quote with no depth behind it is refused rather than returned — a dust-pool price is worse than no price when an agent may trade on it.
This package contains no private key, no seed and no funded wallet. Payment is opt-in and off unless you set a key yourself; a package strangers install must never move funds because a model called a tool a few extra times.
Set one of these in your MCP client's env block for this server:
{
"mcpServers": {
"dex-data": {
"command": "npx",
"args": ["-y", "dex-data-mcp"],
"env": { "DEX_WALLET_KEY": "0x<64 hex chars>" }
}
}
}EVM_PRIVATE_KEY is accepted as an alias — it is the name the CDP x402 docs use
and the name bsc-dex-spread-mcp read, so an existing config for that package
keeps working unchanged.
Fund it with USDC on Base and nothing else. x402's exact scheme is
EIP-3009: you sign an off-chain authorization and the facilitator broadcasts and
pays the gas, so the wallet needs zero ETH.
Use a burner. The key sits in your MCP client config in plaintext. A few dollars of USDC, never a main wallet.
Spend is capped and fails closed — DEX_MAX_SPEND_USD (default $1 total for
the process), DEX_MAX_PRICE_USD (default $0.05 for any single call) and
DEX_MAX_CALLS (default 200). Hitting any one stops payment and returns a plain
explanation rather than continuing to spend. The asking price is read from the
402 challenge and refused before paying if it exceeds the ceiling.
get_spend_budget reports what this session has spent and the caps in force.
Without a wallet, get_dex_spread returns the price, the two env var names, the
shape of the value and the free alternatives — never a stack trace, and never a
silent failure.
Depth and prices cover the venues this API indexes; a deeper pool may exist on a DEX not covered here.
v3 figures distinguish custody TVL from tradeable depth at the current price. They are not the same number and are not labelled as if they were.
get_slippage is pool-level price impact: it excludes gas, MEV and multi-hop
routing, and flags v3 estimates that cross the active tick band.
A tool called without its required argument is refused before any request is
made, so a malformed call never spends a free-tier slot or a cent. The refusal
names the argument: search needs q, get_slippage needs amountUsd or
amountIn, lookup_lei needs q or lei.
Cross-DEX spread only, on six chains — arb-dex-mcp
is the focused sibling: npx -y arb-dex-mcp. Keyless too, and its free answers
carry a limitation field naming exactly what a key would add.
Paid, per-call BSC spread — that is now the get_dex_spread tool in this
package; you do not need a second install. It was previously the standalone
bsc-dex-spread-mcp, which
still works and is unchanged, but this server is where it is maintained.
You want the compliance pair (OFAC screening, GLEIF LEI) —
agent-utils-mcp.
You want the human-approval job queue this whole stack is operated by —
approval-queue-starter,
one file, zero dependencies.
The weekly measurements, free — https://arbdatadesk.beehiiv.com. The live dashboard — https://arb-dex-data-production.up.railway.app/dashboard.
Scan a chain for cross-venue arbitrage right now: pairs whose price differs enough between DEXes to be worth trading, ranked by GROSS USD AT THE OPTIMAL TRADE SIZE — not by raw spread, because a wide spread on a tiny pool is not an opportunity. Returns an empty list when there is nothing, which is a real answer. Excludes gas, MEV and execution risk.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | Chain to query. Defaults to bsc. | |
| minSpreadBps | No | Minimum cross-venue spread in basis points. Default 20. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It transparently discloses that results are ranked by gross USD at optimal trade size, not raw spread, that an empty list is a valid result, and that gas, MEV, and execution risk are excluded. This provides clear behavioral expectations.
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 is compact and each sentence adds value: it defines the scope, the ranking method, the empty-list behavior, and the exclusions. It is slightly verbose but not redundant.
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?
There is no output schema, but the description indicates the output is a ranked list of opportunities and explicitly states the empty-list case. It also clarifies what is excluded, giving enough context for an agent to interpret results. Minor gaps remain about the exact output format or fields.
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?
The schema provides 100% coverage for parameters, each with a description (chain, minSpreadBps). The tool description adds context about ranking by gross USD, but does not add significant new meaning to the parameters beyond what is already in the schema. Baseline 3 is appropriate.
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 clearly states the tool scans a chain for cross-venue arbitrage opportunities, using the specific verb 'scan' and resource 'chain'. It differentiates from siblings like get_dex_spread and get_best_venue by focusing on a cross-venue, chain-wide scan rather than a specific pair.
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 description mentions 'right now' indicating real-time scanning, but does not explicitly state when to prefer this tool over alternatives such as get_dex_spread or get_best_venue. Some guidance is implied by the scope (chain-wide vs. specific pair), but it is not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert a street address, city or place name to latitude/longitude coordinates — worldwide, via OpenStreetMap. Returns coordinates, display name, structured address parts and a confidence score. No match returns a clear 404, never a guessed coordinate.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Address or place name, e.g. "Eiffel Tower, Paris". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description clearly discloses return content, the 404 failure mode, and the guarantee of never guessing coordinates. It does not mention rate limits or authentication, but these are less critical for a simple read-only geocoding tool.
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 compact sentences, all informative, with no redundant or filler content. Key constraints (worldwide, via OpenStreetMap, no guessing) are front-loaded.
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 single parameter, no output schema, and clear return/failure semantics, the description covers everything an agent needs to call the tool correctly.
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% for the single query parameter, and the description adds a concrete example ('Eiffel Tower, Paris') plus clarifies acceptable input types (address, city, place name).
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 ('Convert') and resource (street address/city/place name to coordinates), and clearly distinguishes itself from siblings like reverse_geocode and geolocate_ip.
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?
Implicitly conveys forward geocoding usage through its resource description and return values, though it does not explicitly name alternative tools or conditions for when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Locate a public IPv4 or IPv6 address: country, region, city, postcode, coordinates, timezone, ASN, org and ISP. Datacentre/VPN/proxy/Tor detection is returned FIRST because it decides whether the location means anything — and when the upstream does not supply that detection the answer says unknown, never clean. An IP locates a network, not a person: the coordinates are a registered-range centroid, so never present them as where someone is.
| Name | Required | Description | Default |
|---|---|---|---|
| ip | Yes | Public IPv4 or IPv6 address. Private and reserved ranges are refused. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description fully discloses behavior: it explains that detection result is prioritized, that unknown detection is possible ('never clean' means it won't falsely claim a clean status), and that coordinates are a centroid, not an exact location. This transparency is excellent.
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 is compact yet comprehensive. It packs essential information (output fields, detection logic, limitations) into three sentences, each serving a clear purpose, with no redundant or vague phrasing.
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 there is no output schema, the description compensates by enumerating the specific data fields returned (country, region, city, postcode, coordinates, timezone, ASN, org, ISP). It also explains the additional detection field and its role, making the tool's behavior fully understandable without further documentation.
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?
The only parameter, 'ip', is fully described: it accepts public IPv4 or IPv6 addresses and explicitly states that private and reserved ranges are refused. This covers both format and constraints, leaving no ambiguity.
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 clearly states the tool's purpose: locating a public IPv4 or IPv6 address and returning detailed location and network information. It explicitly lists the output fields (country, region, city, etc.), making the tool's function unambiguous.
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 description provides practical usage guidance by noting that detection of datacentre/VPN/proxy/Tor is returned first and that this determines the reliability of the location. It also cautions against interpreting IP coordinates as the exact physical location of a person, which helps set expectations. However, it does not explicitly compare with sibling tools or state when to prefer this tool over others, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Which DEX is cheapest to buy on and which pays most to sell into, with the cross-venue spread in bps and a fee-adjusted arbitrage spread. Smart order routing data.
| Name | Required | Description | Default |
|---|---|---|---|
| pair | Yes | Pair as SYM/SYM. | |
| chain | No | Chain to query. Defaults to bsc. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not mention side effects, permissions, rate limits, or whether the tool is read-only. It is likely a read-only query tool, but this is not disclosed, leaving the agent without full transparency.
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 is concise, using only two sentences to convey the core functionality and expected outputs. It avoids unnecessary detail and is easy to parse.
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?
The description mentions key outputs (cross-venue spread in bps, fee-adjusted arbitrage spread) but does not specify the exact structure of the return value. Since there is no output schema, this is sufficient for a simple query tool, though slightly more detail would improve completeness.
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?
The schema covers both parameters with descriptions (pair as SYM/SYM, chain with enum and default), providing 100% coverage. The descriptions are minimal but adequate. The main description adds no additional per-parameter context, so the baseline score of 3 is appropriate.
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 clearly states the tool's purpose: identifying the cheapest DEX to buy and the most profitable to sell for a given pair, while also providing cross-venue spread and fee-adjusted arbitrage spread. This is specific and distinguishes it from similar sibling tools like get_dex_spread or find_arbitrage.
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 description implies it is for smart order routing and comparing venues, but it does not explicitly state when to use this tool over alternatives such as get_dex_spread or get_pool_reserves. The differentiation is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PAID ($0.01 USDC/call, no free tier). Real-time cross-DEX price & spread for BSC: per-venue prices across PancakeSwap v2, PancakeSwap v3 (all fee tiers), Biswap and ApeSwap in one call, plus best buy/sell venue, gross arbitrage spread (bps + USD), optimal trade size, liquidity and block number. Params: pair=SYM/SYM (e.g. WBNB/USDC), optional fee=v3 tier. Needs a funded wallet in DEX_WALLET_KEY or EVM_PRIVATE_KEY; without one it returns payment instructions and spends nothing. Cheaper alternatives in this same server, free for 25 calls/day and no wallet: "get_liquidity" for per-venue depth and "find_arbitrage" for a cross-venue spread scan.
| Name | Required | Description | Default |
|---|---|---|---|
| fee | No | Optional PancakeSwap v3 fee tier to restrict the v3 probe (e.g. 100, 500, 2500, 10000). Omit to probe all v3 tiers + v2. | |
| pair | Yes | Token pair as SYM/SYM; first symbol is the USD-priceable side (e.g. WBNB/USDC, WBNB/USDT, CAKE/WBNB). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden and does so well: it discloses cost, wallet requirement, and that it spends nothing without a funded wallet. It also enumerates the returned data, making side effects and behavior transparent.
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 is a dense run-on but packs all essential information up front (cost, purpose, parameters, wallet, alternatives). It is longer than necessary but organized in a natural flow from cost to functionality to requirements to alternatives, making it easy to scan.
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 no output schema or annotations, the description thoroughly covers inputs, outputs, costs, prerequisites, and alternative tools. An agent has enough context to decide whether to call this tool and what to expect in return.
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 covers 100% of parameters, so baseline is 3. The description adds value by providing example formats (WBNB/USDC) and clarifying that the first symbol is the USD-priceable side, and explaining fee tiers and omission behavior. Slightly redundant with schema but enhances usability.
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?
Clearly states it provides real-time cross-DEX price and spread for BSC across specific venues, plus best buy/sell venue, gross arbitrage spread, optimal trade size, liquidity, and block number. Explicitly contrasts with cheaper alternatives get_liquidity and find_arbitrage, distinguishing it from siblings.
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 notes it is paid ($0.01 USDC/call, no free tier), requires a funded wallet, and without one returns payment instructions and spends nothing. Directly tells when to use the free alternatives instead, giving clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Live gas prices across BNB Chain, Polygon, Arbitrum, Base, Avalanche and Optimism, priced in USD and ranked cheapest-first. Returns gas price in gwei, base fee, and what a transfer, an ERC-20 transfer and a swap actually cost in dollars on each chain. Gwei is NOT comparable across chains because the gas token differs in price, so USD is the only ranking that says where a transaction really costs least. For bridging, routing and execution timing.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | One chain, or "all" for every chain ranked cheapest-first. Defaults to all. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It clearly states the tool returns data ('Returns gas price in gwei') and emphasizes 'Live gas prices', indicating a read-only, informational operation with no destructive side effects mentioned.
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 sentence structure twice (listing gwei, base fee, and USD costs), making it more verbose than necessary. It could be trimmed to a single clear statement without losing meaning.
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?
Despite lacking an output schema, the description enumerates the exact returned fields (gas price in gwei, base fee, USD costs for transfer/ERC-20/swap) and the ordering behavior, giving an agent sufficient context to correctly use the tool and interpret results.
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?
The schema covers 100% of parameters with an enum and description. The description adds value by clarifying that omitting the chain defaults to 'all' and that results are ranked cheapest-first, enhancing the schema's basic enum listing.
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 clearly states the tool retrieves live gas prices across multiple specific chains (BNB Chain, Polygon, Arbitrum, Base, Avalanche, Optimism) and outputs them ranked cheapest-first, which differentiates it from pricing, liquidity, and venue tools in the sibling list.
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 description implies usage for bridging, routing, and execution timing, but does not explicitly state when to prefer this tool over alternatives like get_token_price or get_slippage. The context is present but could be more direct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Public and bank holidays for 100+ countries, and the business-day question behind them. Pass a date and it answers directly whether that date is a business day and what the next and previous ones are, counting weekends and holidays and walking across year boundaries. Without a date it returns the whole year, including which regions observe a non-national holiday. Regional closures, half-days and market trading calendars are not covered.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | YYYY-MM-DD. Adds isBusinessDay plus next/previous business days. | |
| year | No | Calendar year 1975..2100. Default: current year. Ignored when date is given. | |
| country | Yes | ISO 3166-1 alpha-2 country code, e.g. US, GB, DE, JP. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It transparently explains weekend/holiday counting, year-boundary walking, whole-year behavior, and exclusions. It could go further by describing the exact response shape or edge cases such as invalid input, but for a read-style holiday tool the behavior is disclosed well.
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?
Four sentences, all earning their place: the first states the core purpose, the second covers date mode, the third covers year mode, and the fourth names exclusions. The most important information appears first and no filler is present.
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 the simple parameter set and the absence of an output schema, the description supplies the key return semantics: whether a date is a business day, next/previous business days, whole-year data without a date, and regional observation details. It also explicitly disclaims unsupported cases, making the tool safe to select in mixed contexts.
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 the schema already describes each parameter, which justifies a baseline of 3. The description adds useful parameter-level meaning beyond the schema: date triggers business-day calculations including year boundaries, and omitting date returns the entire year with regional observation details. That exceeds the baseline.
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 names the exact resource (public and bank holidays for 100+ countries) and the concrete operations: determining whether a date is a business day and finding next/previous business days. It also distinguishes its scope from sibling tools by explicitly marking what it does and what it does not cover.
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?
It gives two explicit invocation modes: pass a date for a business-day answer, or omit a date to get the whole year. It also clearly states exclusions, warning that regional closures, half-days, and market trading calendars are not covered. No competing holiday/business-day sibling exists, so the guidance is complete enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Market depth and TVL for a trading pair, broken down per venue: how deep the pools are, which venue holds the most liquidity, and each venue share of total depth.
| Name | Required | Description | Default |
|---|---|---|---|
| pair | Yes | Pair as SYM/SYM, e.g. WETH/USDC. Either side may be a 0x address. | |
| chain | No | Chain to query. Defaults to bsc. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It does not mention whether the operation is read-only, any side effects, authentication requirements, rate limits, or error behavior. Given the lack of annotations, this is a significant gap.
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 is two sentences and efficiently packs the tool's purpose and key output details without any redundant or promotional language. It is well-structured and easy to parse.
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?
The description outlines the nature of the return data (per-venue depth, TVL, best venue, share of total depth), which is helpful given the absence of an output schema. However, it omits details such as expected format, units, or any caveats about data freshness or availability, though the absence is not critical. Overall it provides sufficient context for basic usage.
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?
Both parameters are fully described in the schema. 'pair' specifies the format (SYM/SYM) with a concrete example and notes that either side may be a 0x address. 'chain' provides an explicit enum of allowed values and a default. The schema coverage is 100%.
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 clearly states the tool returns market depth and TVL for a trading pair, per venue, and explicitly lists the key outputs (pool depth, best venue, share of total depth). The verb 'get' and resource 'liquidity' are unambiguous, and it distinguishes itself from the many sibling tools that focus on a single venue or different metrics.
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 description explains what the tool does but does not explicitly state when to choose it over similar siblings like 'get_pool_reserves' or 'get_best_venue'. It implies use for per-venue liquidity breakdowns, but this guidance is implicit rather than explicit, leaving room for ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pre-trade depth check for a pair: classifies the market DEEP, MODERATE, SHALLOW or VERY_THIN from live pool TVL, counts routable venues, and flags single-venue markets and wide spreads. Liquidity depth analysis only — NOT a contract audit and NOT a honeypot check.
| Name | Required | Description | Default |
|---|---|---|---|
| pair | Yes | Pair as SYM/SYM. | |
| chain | No | Chain to query. Defaults to bsc. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes the analysis outputs: market classification, venue count, and flags for single-venue markets and wide spreads. It also clarifies it is liquidity depth analysis only, but does not describe any side effects or error behavior, which is acceptable for a read-only analysis.
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 is a single, focused sentence that conveys the tool's purpose and constraints without unnecessary detail. It is well-structured and easy to parse.
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?
Provides enough context for an agent to decide when to use it, including exclusions. It lacks details on classification thresholds or return format, and does not explain what constitutes a wide spread, but these are not essential for correct selection.
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?
The schema already provides full coverage for both parameters (pair, chain with enum and default), so the description adds no additional parameter semantics beyond the schema. Baseline 3 is appropriate since coverage is high and the description does not deepen parameter meaning.
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 action 'Pre-trade depth check' and resource 'pair', and explicitly distinguishes itself from contract audits and honeypot checks, making its purpose unambiguous. It also sets expectations by noting it is liquidity depth analysis only.
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?
Implies usage before trading, and clearly states what it is not ('NOT a contract audit and NOT a honeypot check'), which helps an agent avoid misusing it. However, it does not name alternative sibling tools for those excluded purposes, so the guidance is not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Raw pool reserves for a pair on every indexed venue: the two token balances, the pool fee in bps, the implied price from those reserves and the pool TVL, all read at one block height which is returned with the answer. This is the underlying data the price, depth and slippage tools are computed from — use it when you want to do your own maths rather than take ours.
| Name | Required | Description | Default |
|---|---|---|---|
| pair | Yes | Pair as SYM/SYM, e.g. WBNB/USDT. Either side may be a 0x address. | |
| chain | No | Chain to query. Defaults to bsc. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It transparently enumerates the returned data (balances, fee, price, TVL, block height) and the scope (every venue). It does not mention read-only behavior explicitly, but that is implied by the nature of querying reserves, and the description is sufficiently transparent for a read-only tool.
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 is two sentences, tightly packed with relevant information: what data is returned, the scope, and a usage directive. No redundant or filler content; each sentence earns its place.
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 there is no output schema, the description compensates by fully listing the return fields (balances, fee, price, TVL, block height) and the aggregation across venues. It also provides context on how this data relates to other tools, making it complete for an agent to decide and invoke correctly.
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 the baseline is 3. The description for 'pair' and 'chain' in the schema already provide clear definitions and examples; the tool description adds no further semantic detail beyond what is already in the parameter descriptions.
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 clearly states the verb 'get' with resource 'pool reserves' and scope 'for a pair on every venue'. It also differentiates from sibling tools by noting this exposes raw data underlying the price, depth, and slippage tools, and directs users who want to do their own calculations.
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 provides when to use this tool: 'use it when you want to do your own maths rather than take ours.' This gives clear guidance on alternatives and the context for selection, satisfying the criteria for usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cryptographically secure randomness for agents that are deterministic or sandboxed and cannot generate their own: uniform integers in [min, max] (rejection-sampled, no modulo bias) or raw random bytes as hex and base64. For nonces, IDs, sampling and shuffling.
| Name | Required | Description | Default |
|---|---|---|---|
| max | No | Upper bound (inclusive) for integer mode. | |
| min | No | With max: return uniform integers in [min, max] inclusive. | |
| bytes | No | Random bytes to return, 1..1024. Default 32 when no integer range is given. | |
| count | No | How many integers, 1..1000. Integer mode only. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses cryptographic security, rejection sampling to avoid modulo bias, and output formats. This is transparent about the tool's behavior and guarantees.
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 is information-dense but not overly long. It front-loads the core purpose and then details specifics, making it efficient to parse.
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?
No output schema exists, but the description explains what is returned (integers or bytes in hex/base64) and the modes. This is adequate for an agent to understand the tool's output without further detail.
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?
Despite 100% schema coverage, the description adds crucial context: 'inclusive' bounds, default of 32 bytes, and that count applies only in integer mode. This clarifies parameter behavior beyond the schema.
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 clearly states the tool provides cryptographically secure randomness, either uniform integers in a range or random bytes in hex/base64. This distinguishes it from sibling tools that focus on data retrieval or calculations.
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?
It explicitly mentions use cases like nonces, IDs, sampling, and shuffling, giving clear guidance on when to invoke. It does not explicitly mention when not to use, but the purpose is sufficiently specific.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What people actually type into a search box for a topic — live search autocomplete, expanded across question modifiers (how/what/why/is/can/does) and comparison modifiers (vs/or), then split into suggestions, questions and comparisons. Rows where the engine dropped your term and answered something else are filtered out and counted. A demand signal for content and keyword research, not a ranking — search volume is not published upstream and is not invented.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Topic or search terms, max 200 characters. | |
| lang | No | Language code, default "en". | |
| depth | No | "full" (default) expands across 15 modifiers; "basic" returns completions for the query alone. | |
| country | No | Two-letter market code, default "us". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses that it is not a ranking and that it filters out dropped terms, and it explains the output format (suggestions, questions, comparisons). It does not mention rate limits or API-side behaviors, but the data-processing transparency is good.
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 is two sentences and relatively concise, though it uses dense phrasing like 'live search autocomplete, expanded across question modifiers'. It stays focused on the tool's function and output without unnecessary detail.
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?
Although there is no output schema, the description explains the return structure ('split into suggestions, questions and comparisons') and the filtering behavior, which is sufficient for an agent to understand what the tool will produce. It lacks explicit examples or edge-case handling, but covers essential context.
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?
The schema provides 100% coverage of parameter descriptions, so the description adds no extra value for parameters. It merely restates the schema's semantics (e.g., 'expanded across question modifiers' relates to depth, but this is not explicitly linked). The baseline for high schema coverage is 3, and the description does not elevate it.
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 clearly states the tool's purpose: to retrieve search autocomplete suggestions for a topic, expanded across question and comparison modifiers. It explicitly differentiates it from ranking tools, calling it 'a demand signal for content and keyword research, not a ranking', which distinguishes it from siblings like 'search'.
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?
It implies when to use the tool (for demand research) and notes that rows where the engine dropped the term are filtered out, giving insight into data handling. However, it does not explicitly mention alternative tools or provide a direct 'use this when' statement, though the context makes this clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Price impact for a SPECIFIC trade size — what a trade will actually get, which a spot price cannot tell you. Simulates the swap against live reserves on every venue. Price impact and the pool fee are reported separately. Pool-level only: excludes gas, MEV and multi-hop routing.
| Name | Required | Description | Default |
|---|---|---|---|
| pair | Yes | Pair as SYM/SYM. | |
| chain | No | Chain to query. Defaults to bsc. | |
| amountIn | No | Alternatively, size in units of the first token. Supplying either this or amountUsd is enough. | |
| amountUsd | No | Trade size in USD, e.g. 10000. Required unless amountIn is given instead — slippage is meaningless without a size. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses behavior: simulates against live reserves, reports price impact and fee separately, and explicitly states exclusions (gas, MEV, multi-hop). It does not explicitly state side effects (e.g., read-only), but the nature of a simulation query implies no destructive actions.
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 is concise (two sentences) and dense with relevant information: purpose, simulation mechanics, output details (fee reported separately), and scope exclusions. Every sentence adds value without redundancy or fluff.
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?
The description covers the essential aspects: what it returns (price impact and fee), scope (pool-level), and exclusions. It does not mention error handling or output format, but no output schema exists and the tool's simplicity allows this to be sufficient. The 'every venue' phrasing could be ambiguous, but overall it provides enough context for an agent to invoke it correctly.
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% (all parameters described). The description adds crucial context beyond the schema: it clarifies the relationship between amountIn and amountUsd ('Required unless amountIn is given instead — slippage is meaningless without a size'), making the parameter semantics clearer than the schema alone.
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 clearly states the tool's purpose: to calculate price impact for a specific trade size, distinguishing it from spot price. It specifies the resource (slippage/price impact) and action (simulates swaps), and sets expectations by noting it reports fee separately and excludes gas/MEV/multi-hop.
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 description indicates when to use it (when spot price is insufficient for a specific trade size) and provides scope limitations (pool-level only, excludes gas/MEV/multi-hop). It does not explicitly name alternative tools, but the context from sibling tools and the 'which a spot price cannot tell you' phrasing provides adequate guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
How much this session has spent on paid calls, and the caps in force. Free, local, and makes the cost of continuing visible before it is incurred.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description openly states that the tool is free and local, indicating no side effects or network calls. It does not mention rate limits or other constraints, but given its read-only nature, the transparency is adequate.
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 is succinct, using a single sentence to convey the purpose and key attributes. Every word contributes to the meaning without unnecessary detail.
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 tool with no parameters and no output schema, the description fully covers its purpose, cost implications, and local execution. It provides sufficient context for an agent to decide when and how to invoke it.
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?
The tool has no parameters and the schema is fully covered (100%), so the description adds no parameter-specific information. The baseline of 3 applies as there is nothing to clarify.
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 clearly states that the tool reports the amount spent on paid calls and the active caps. It is specific and immediately understandable, leaving no ambiguity about its function.
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 description implies when to use it (to check budget before incurring more costs) and notes it is free and local, but does not explicitly contrast with sibling tools or state a precise trigger condition. Still, the context is inferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Live USD price of any ERC-20 token, read from DEX pools at call time. Accepts a ticker (CAKE, WETH, ARB) or any contract address. Returns the price, the pair it was priced through, the USD liquidity backing that quote and a confidence rating. Refuses to return a price backed by a dust pool rather than reporting an unreliable number.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | Chain to query. Defaults to bsc. | |
| token | Yes | Ticker (e.g. CAKE) or 0x contract address. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explains what the tool returns (price, pair, liquidity, confidence) and a specific refusal case (dust pool). It does not cover all error scenarios, but the core behavior is transparent.
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 is concise, well-structured, and free of redundant information. It efficiently communicates functionality, inputs, outputs, and a key edge-case refusal in a single paragraph.
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 there is no output schema, the description adequately explains the return payload. It also mentions the refusal condition and input flexibility. It does not address potential errors (e.g., invalid token), but overall it provides sufficient context for an agent to decide and invoke the 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?
The schema covers both parameters with descriptions. The tool description adds value by providing concrete examples for token (CAKE, WETH, ARB) and clarifying that any contract address is accepted. This enhances understanding beyond the schema.
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 clearly states the tool's purpose: retrieving live USD prices for ERC-20 tokens from DEX pools. It distinguishes itself from sibling tools like get_liquidity or get_best_venue by focusing on price with specific output details.
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 description provides conditions for use (accepts ticker or contract address) and a refusal condition (dust pool), but does not explicitly contrast with alternatives or state when to prefer this tool over siblings. This leaves some inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The US Treasury par yield curve for any published business day — every constant-maturity rate from 1 month to 30 years — plus the spreads and the inversion flag, because the real question is whether the curve is inverted rather than what fourteen numbers are. 2s10s, 3m10y and 5s30s are computed for you. A tenor Treasury did not publish that day is null, never zero. Nominal CMT rates: not real yields and not zero-coupon spot rates.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | YYYY-MM-DD business day. Default: the latest published curve. A non-publication day returns the available range, not a nearest guess. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the behavioral disclosure burden. It reveals the return format (all maturities, spreads, inversion flag), the null handling for unpublished tenors, the non-publication day fallback to available range, and explicitly disambiguates the rate type (nominal CMT, not real or zero-coupon). This is comprehensive and leaves no critical behavior unstated.
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 is informative and well-structured, front-loading the core purpose and then adding important details about null handling and rate type. The conversational aside ('because the real question...') adds character but is slightly tangential; still, the overall length is acceptable and every substantive detail earns its place.
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 single-parameter tool with no output schema, the description is complete: it specifies all return components, edge cases, and data semantics. An agent can accurately predict the tool's behavior and results without needing additional context. There are no missing elements.
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%, and the parameter description already explains the format, default, and non-publication behavior. The tool description adds no new parameter-level information beyond what the schema provides, so the baseline of 3 is appropriate. It does not need to compensate because the schema is already explicit.
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 states a specific verb and resource: retrieves the US Treasury par yield curve for a given business day, enumerating the exact outputs (all constant-maturity rates, spreads, inversion flag). It is clearly distinct from all sibling tools, which deal with crypto, geolocation, or other domains, so there is no ambiguity.
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?
While there are no closely related sibling tools to contrast, the description gives explicit usage context: it specifies the date parameter behavior, explains that unpublished tenors are null rather than zero, and clarifies that these are nominal CMT rates, not real or zero-coupon yields. This effectively tells an agent when and how to interpret the results, though it does not mention alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Current weather and up to a 7-day forecast for any coordinates worldwide: temperature, feels-like, humidity, precipitation, wind speed/gusts/direction now, plus daily highs, lows and precipitation probability. Model forecast, not a station reading — the response says so. Use the geocode tool first if you have a place name rather than coordinates.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | Latitude, -90..90. | |
| lon | Yes | Longitude, -180..180. | |
| days | No | Forecast days, 1..7. Default 3. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the data is a model forecast and not a station reading, and notes that the response will indicate this. It does not mention side effects or read-only nature, but for a simple 'get' tool this is adequate. Since no annotations are provided, the description carries the burden and covers the most important behavioral aspect.
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 is two concise sentences with no redundancy or fluff. It efficiently conveys the core purpose, output contents, a clarifying note, and usage guidance without unnecessary words.
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?
Although there is no output schema, the description explicitly lists the output fields (temperature, feels-like, humidity, precipitation, wind speed/gusts, daily highs/lows, precipitation probability). This gives a comprehensive understanding of what to expect, and the geocode note provides necessary context for input handling.
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?
The schema already provides full descriptions for lat, lon, and days (coverage 100%). The tool description repeats these descriptions without adding extra meaning such as units or default behavior beyond what the schema already states, so the baseline score of 3 is appropriate.
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 clearly states the tool provides current weather and a 7-day forecast for coordinates, and explicitly distinguishes it from station readings and directs users to geocode for place names. This leaves no ambiguity about the tool's 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 description explicitly instructs to use the geocode tool first when a place name is provided instead of coordinates, providing clear when-to-use and when-not-to-use guidance. No other weather siblings exist, so no alternative is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Supported chains, their indexed tokens and venues. Free, and the right first call if you are unsure which chain or ticker to use.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses that the tool is 'Free' (a cost trait) and implies a read-only list operation. However, it doesn't detail potential side effects, rate limits, or response structure. Given the simplicity of a parameterless listing tool, this is adequate, but not exhaustive.
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 entire description is a single sentence that front-loads the main purpose ('Supported chains, their indexed tokens and venues') and then provides usage guidance. There is no redundancy or filler, making it highly efficient.
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 parameterless tool with no output schema, the description tells the agent what the tool returns (chains, tokens, venues) and when to use it. This is sufficient for the agent to decide to call it without additional details.
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?
The tool has 0 parameters, so schema coverage is trivially 100%. The description doesn't need to explain parameters; instead it describes the resource output, which is the relevant information for the agent. This meets the baseline for a zero-parameter 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 clearly states the tool lists supported chains, their indexed tokens, and venues. It uses a specific verb ('list') and resource ('supported chains, indexed tokens, venues'), and distinguishes itself from siblings by positioning as the first call for disambiguation.
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 description explicitly states when to use it: 'the right first call if you are unsure which chain or ticker to use.' This provides clear usage context and differentiates it from sibling tools that answer specific queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up a company in the GLEIF Legal Entity Identifier golden copy BY NAME, not just by identifier — knowing the LEI already is the hard part. Returns the LEI, registered legal name, previous names, legal form, jurisdiction, legal and headquarters addresses and the registration record. Lapsed, retired and annulled entities come back flagged rather than filtered out: a hidden record and no record are indistinguishable to the caller.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Legal entity name, max 200 chars. A bare brand name works — "Apple" finds Apple Inc. Results are ranked by name match across the legal name and any alternative names. | |
| lei | No | Exact 20-character LEI, for a single record instead of a name search. | |
| limit | No | Maximum name-search results, 1..50. Default 10. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behavioral aspects: results are ranked by name match, and lapsed/retired/annulled entities are flagged instead of filtered, with a note that a hidden record is indistinguishable from no record. This goes beyond basic functionality but does not cover pagination, error handling, or other edge-case behaviors.
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 is concise and well-structured. It opens with the primary usage scenario, lists return fields in a single sentence, and adds a clarifying behavioral note. No unnecessary verbosity or confusing phrasing.
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?
The description provides sufficient context for an agent to understand the tool's purpose, inputs, and output fields. It lacks an output schema but compensates with a clear field list. It does not explicitly address when to use this tool vs. siblings, but the name-based lookup focus is implicit.
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?
All three parameters (q, lei, limit) have clear, detailed descriptions covering purpose, constraints (max length, exact LEI format, range), and defaults. Schema coverage is 100% and each parameter's semantics are fully explained.
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 clearly states the tool's purpose: looking up a company by name (or LEI) in the GLEIF golden copy, and explicitly contrasts it with identifier-based lookup. It also lists the exact fields returned, leaving no ambiguity about what the tool does.
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 description implies usage for name-based lookups ('knowing the LEI already is the hard part') and notes that lapsed/retired entities are flagged rather than filtered. However, it does not explicitly state when to prefer this tool over sibling tools or provide decision criteria beyond the name-vs-identifier distinction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read any public RSS, Atom or RDF feed as clean JSON: feed title, link and description, then items with title, real destination link, author, categories and the published date both verbatim and normalised to ISO 8601. Each summary is returned twice — the feed HTML as published, and a plain-text rendering safe to put straight into a prompt. An unparseable date is null, never an invented timestamp. Pair with url_to_markdown to read a linked article.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Public http(s) URL of an RSS 2.0, Atom or RDF feed. | |
| limit | No | Maximum items, 1..100. Default 20. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses behavior: returns clean JSON, includes date normalization, null for unparseable dates, summaries in HTML and plain-text, and 'real destination link' implying redirect resolution. Missing auth/rate-limit details but these may be irrelevant for a read-only public feed tool.
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 is a few sentences but dense with useful information, front-loading the purpose and then detailing output structure and date handling. No fluff, though it could be slightly more concise without losing value.
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 tool with two parameters and no output schema, the description is fairly complete: it explains the output structure, date behavior, and even mentions a sibling tool. It doesn't cover error scenarios or edge cases (e.g., invalid URL), but these are not critical for a read-only feed fetcher.
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% for both parameters, so the baseline is 3. The description does not add extra meaning beyond the schema; it mentions the URL type but does not elaborate on limit or its default. Since the schema already documents them, this is acceptable.
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?
Description states a clear verb 'Read' and resource 'any public RSS, Atom or RDF feed' and specifies output as clean JSON with feed and item fields. It distinguishes itself from url_to_markdown by noting it reads the feed itself, not the linked article.
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 pairs with url_to_markdown for reading linked articles, providing a clear alternative and context. However, it doesn't give explicit 'when not to use' conditions beyond that pairing, but the context is sufficient for an agent to choose appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert latitude/longitude coordinates to the nearest street address and place name — worldwide, via OpenStreetMap. Coordinates in the ocean or unmapped return 404, never a fabricated address.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | Latitude, -90..90. | |
| lon | Yes | Longitude, -180..180. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses a key behavioral edge case: ocean/unmapped coordinates return 404 and never fabricate an address. This exceeds basic annotation coverage and sets accurate expectations.
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?
Two concise sentences fully convey purpose and critical behavior without unnecessary detail.
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?
The description is sufficient for an agent to understand the tool's function and main limitation, though it does not specify output format or exact response shape. Given the simple input schema and clear purpose, this is acceptable.
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?
The schema already documents both parameters with ranges; the description adds the semantic purpose of these coordinates in the context of reverse geocoding, slightly enhancing understanding.
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 ('Convert') and resource ('latitude/longitude coordinates' to 'nearest street address and place name'), and differentiates from sibling 'geocode' by specifying reverse geocoding via OpenStreetMap.
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?
Clearly describes the tool's purpose and distinguishes from the forward 'geocode' sibling implicitly. It does not explicitly state when not to use it, but the context and wording make the use case clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Web search — a free-text query returns ranked organic results, each with title, real destination URL, display URL and snippet. Sponsored rows are excluded. Up to 25 results; count is a maximum, not a guarantee, because a row whose destination cannot be resolved is dropped rather than guessed at. Results are not fetched or verified — pair with url_to_markdown to read any result.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Search terms, max 500 characters. | |
| count | No | Maximum results, 1..25. Default 10. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the behavioral safety profile, and it exceeds expectations: it states count is a maximum not a guarantee, unresolved destinations are dropped rather than guessed at, sponsored rows are excluded, and results are not fetched or verified. These precise edge-behaviors are exactly what an agent needs to call it blindly.
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 definition is two sentences with no filler: it front-loads the exact resource and action, then packs edge cases and usage notes briefly. The 'pair with' instruction at the end earns its place as it improves agent execution.
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, the description still explains exactly what the returned results look like (title, real URL, display URL, snippet), what they exclude, and what happens in the face of unresolved destinations. It also names the natural next step (url_to_markdown). This is complete for a simple two-parameter search 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?
The schema already fully describes 'q' and 'count' with ranges and defaults, so the description does not need to add every edge. It adds meaningful contract beyond the schema by explaining that the declared number of results is a cap, not a promise, and why fewer results may be returned. That is more than a baseline, but the parameter descriptions themselves are already strong.
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 leads with 'Web search — a free-text query returns ranked organic results', which is a specific verb+resource+outcome. It details the result fields, excludes sponsored arrays, and states the hard limit of up to 25, clearly setting it apart from siblings like get_search_suggestions and url_to_markdown.
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?
It gives clear context on when this tool is used ('free-text query', returns ranked organic results) and explicitly routes follow-up consumption to url_to_markdown. It does not provide explicit 'don't use this when...' statements for similar alternatives like get_search_suggestions, so a small inference remains.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a public article or PDF URL and return clean Markdown plus title, byline, site name and word count. HTML is extracted with Firefox reader-mode rules; PDFs return their text layer with page count. Image-only PDFs and client-rendered app shells return typed errors (no_text_layer, not_extractable) instead of empty output passed off as the article.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Public http(s) URL of an article or PDF. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the behavioral transparency burden. It discloses the extraction method (Firefox reader-mode rules), the PDF text-layer behavior with page count, and the typed errors (no_text_layer, not_extractable) for edge cases. This gives the agent a complete picture of expected outcomes and failure modes, exceeding what a typical description provides.
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 is two sentences, front-loaded with the primary purpose and output, and each sentence adds essential information (what it does, how it handles HTML/PDF, and error behavior). There is no fluff or repetition, making it highly efficient.
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 the simplicity of the tool (one parameter, no output schema, no annotations), the description is remarkably complete. It covers the input, the output structure (Markdown plus metadata), the processing method, and specific error cases. Nothing an agent needs to know to call it correctly is missing.
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?
The input schema already provides 100% coverage of the single parameter 'url' with a clear description: 'Public http(s) URL of an article or PDF.' The tool description repeats the same information without adding new semantics or examples, so it adds minimal value beyond the schema. Baseline 3 is appropriate.
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 clearly states the tool's function: fetching a public article or PDF URL and returning clean Markdown plus metadata (title, byline, site name, word count). It distinguishes from siblings like read_feed by specifying the Markdown conversion output and error handling, making it unambiguous.
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 description implies when to use the tool (whenever a URL needs to be converted to Markdown), and notes that it handles both HTML and PDFs. It does not explicitly mention alternatives or when not to use it, but the clear purpose and specific error cases provide sufficient usage context without needing explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0find_arbitragegeocodegeolocate_ipget_best_venueget_dex_spreadget_gasget_holidaysget_liquidityget_liquidity_riskget_pool_reservesget_randomget_search_suggestionsget_slippageget_spend_budgetget_token_priceget_treasury_yield_curveget_weatherlist_chainslookup_leiread_feedreverse_geocodesearchurl_to_markdownScored across 23 tools
Tools are mostly distinct with detailed descriptions, but there is overlap among DEX-related tools (e.g., get_liquidity, get_pool_reserves, get_slippage, get_liquidity_risk, find_arbitrage, get_best_venue, get_dex_spread) that could cause confusion. The extensive descriptions mitigate this, but not entirely.
Naming is inconsistent across tools: many use 'get_' (get_token_price, get_liquidity, get_gas) but others use different verbs (find_arbitrage, list_chains, read_feed, geolocate_ip, lookup_lei, url_to_markdown, geocode, reverse_geocode, search). The pattern is not uniform, though within groups it is consistent.
The server is named 'dex-data' but includes 23 tools, many of which are unrelated to DEX (weather, holidays, random, search, LEI lookup, treasury yields, IP geolocation). This suggests scope creep and a mismatch between the name and the toolset, making the count feel excessive for the stated purpose.
For the broad domain implied by the actual toolset (covering DEX, gas, weather, news, geolocation, financial data), the coverage is fairly comprehensive. However, if the intended domain is strictly DEX data, there are missing features like historical price data or order book depth, but given the mix of tools, completeness is good overall.
Multichain DEX router: free MCP tools for swap-quote prices, chains, catalog; paid via x402.
Pay-per-call DeFi and macro intel for AI agents. x402 USDC tools via streamable HTTP /api/mcp.
Production-grade MCP gateway delivering 8 real-time AI tools with instant x402 micropayments settled in USDC on Base Mainnet or SPL-USDC on Solana. Features Basescan contract auditing, wallet analytics, headless browser scraping, and pre-scraped oracle data feeds.
Production-grade MCP gateway delivering 8 real-time AI tools with instant x402 micropayments settled in USDC on Base Mainnet or SPL-USDC on Solana. Features Basescan contract auditing, wallet analytics, headless browser scraping, and pre-scraped oracle data feeds.
