Loading ToolBench
API query service for blockchain chain data from multiple sources with MCP server support
Chains API demonstrates solid definition quality with well-structured tool names following verb_noun patterns (get_*, search_*, check_*). All 14 tools have explicit schemas defined in mcp-tools.js with type information. Descriptions are generally comprehensive and LLM-optimized, ranging from 120-600+ characters with actionable context. However, several tools lack description details on parameter constraints, and some parameters missing type declarations or descriptions reduce schema completeness. The server excels at domain-specific guidance (e.g., get_chains includes detailed instructions about price data, stale assets, and truncation handling, addressing nuanced agent behavior). Error handling is largely absent from tool descriptions; tools don't document what failures look like or recovery paths. Overall structure and naming conventions are strong, but parameter documentation and error guidance lag behind A-grade standards.
Check whether a chain has STOPPED PRODUCING BLOCKS. Probes the chain's public RPC endpoints live for the latest block (height + block timestamp) and cross-checks a block explorer, then returns a verdict: "halted" (every responding source agrees on the same block and it is overdue), "delayed" (overdue but sources disagree), "endpoint_lagging" (chain is fine, a source is stuck on an old block — NOT a chain problem), "healthy", or "unknown" (fewer than two sources answered — this does NOT mean the chain is down). Use for "is X halted/stuck/stalled", "is X still producing blocks", "is X down". Distinct from get_rpc_monitor_by_id, which reports whether our probe could REACH an endpoint, and from get_live_incidents, which reports what the operator ANNOUNCED.
Get detailed information about a specific blockchain chain by its chain ID. Includes a `price` object for the chain's NATIVE currency (null when unmapped): `{usd, vol24h, marketCap, asOf, stale}`. `vol24h` is that ASSET's 24-hour trading volume in USD — market activity, NOT chain throughput — so an L2 settling in ETH reports ETH's volume, not its own; name the asset when quoting it. When `stale` is true the quote stopped moving at `asOf` (over a day ago): `vol24h` and `marketCap` are null and `usd` is the last known price, to be quoted as of `asOf` rather than as current. A null field is unknown, never zero.
List blockchain chains, optionally filtered by tag (Testnet/L2/Beacon) and/or lifecycle status. Returns a CAPPED sample (default 50, max 200) — `totalMatched` is the full number of chains matching the filter, `count` is how many are in this response, and `truncated` is true when there are more. When `truncated` is true, tell the user you are showing the first `count` of `totalMatched` (a display limit) and offer to narrow by tag/status or search by name — do NOT present the sample as the complete list. For an exact total or category breakdown use get_stats; to find a specific chain use search_chains. Never treat a tag/category count as the overall registry total. Each chain carries a `price` object for its NATIVE currency, or null when the asset is unmapped (only ~29 of ~3000 chains are): `{usd, vol24h, marketCap, asOf, stale}`. `vol24h` is the ASSET's 24-hour trading volume in USD — market activity, NOT chain throughput or transaction count — so chains sharing an asset legitimately report the SAME volume (Optimism, Base and Arbitrum all report ETH's), and you must name the asset when you quote it rather than implying it is that chain's own activity. `asOf` is when CoinGecko last moved the number and `stale` is true when that is over a day old — some assets are still quoted months after their market ended. When `stale` is true, `vol24h` and `marketCap` are null (a closed window is not a weaker answer, it is a different one) and `usd` is the LAST KNOWN price: quote it as of `asOf`, never as current. A null field means unknown, never zero.
Minimal descriptions for 7 tools (search_chains, get_endpoints, get_relations, get_slip44, get_sources, get_keywords, validate_chains). Descriptions under 80 characters lack actionable context about when/why to call these tools or what to expect.
Parameters lack descriptions or type clarity. get_endpoints, get_relations, get_slip44 all accept optional chainId/coinType but descriptions don't explain behavior when omitted (returns all?) or constraints (valid range?).
No error handling or recovery guidance in any tool description. Tools don't indicate what failures are possible, whether they're retryable, or what the agent should try next (e.g., if RPC health check fails, should agent retry or try a different endpoint?).
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 61 | <=2025-11-25 | v2 |
| 2026-03-09 | C | 60 | - | v1 |
Get RPC, firehose, and substreams endpoints for a specific chain or all chains
Get extracted keywords such as blockchain names, network names, software client names, tags, and relation kinds
Get chain relationships (testnet/mainnet, L2/L1, etc.) for a specific chain or all chains
Get RPC monitor status and summary endpoint health counts across all chains (without per-chain endpoint listing)
Get RPC endpoint monitoring results for a specific chain by its chain ID. If the rolling monitor has not reached the chain yet (e.g. right after a deploy), its endpoints are checked live on demand, so a result is normally available.
Get SLIP-0044 coin type information by coin type ID or all coin types
Get the status of all data sources (theGraph, chainlist, chains, slip44)
Get aggregate statistics: total chains, mainnets, testnets, L2s, beacons, RPC health percentage, and a lifecycle breakdown — activeChains (non-deprecated), deprecatedChains, and byStatus (counts per active/incubating/deprecated). Use for "how many chains", "how many are active/deprecated".
Search for blockchain chains by name or other attributes
BFS graph traversal of chain relations from a starting chain. Returns all reachable chains (nodes) and their relationship edges up to a given depth.
Validate chain data for potential quality issues across 17 cross-source validation rules (relation conflicts, slip44/name/status mismatches, L2BEAT consistency, RPC drift, deprecated-parent propagation, and more)
Missing output schema documentation. None of the 14 tool definitions include inputSchema.items, properties detailing what fields the response will contain. LLMs cannot plan downstream calls or extract needed fields (e.g., does get_chains return endpoints, prices, or both? What fields are on each chain object?).
Parameter constraints underdocumented. limit in get_chains accepts max 200 but no min stated; depth in traverse_relations has enum 1-5 in description but not in JSON Schema; no validation guidance on invalid values.
get_sources and get_keywords accept no parameters but descriptions don't explain what data they return or why agent should call them. Discovery tools need context about what information they unlock.