Loading ToolBench
Chainlist MCP has three well-named, read-only tools with clear descriptions and basic input schemas. All tools start with action verbs (list_, get_, find_) and descriptions are concise (40 - 80 chars). However, several parameters lack descriptions, output schemas are not documented, and error handling is minimal. The server follows basic tool patterns but misses LLM-optimization details like parameter constraints, output field documentation, and recovery guidance.
Return RPC endpoints for a chain. https_only=true filters out ws:// + http:// only.
Fetch a single chain by chainId (number) or shortName (e.g. "eth", "matic", "arb1").
Browse or filter the EVM chain registry.
Output schemas not documented. LLMs cannot plan downstream calls or extract fields without knowing what list_chains, get_chain, and find_rpc return. The code shows summarize() and response shapes, but no formal schema is exposed to the client.
Parameter 'https_only' in find_rpc lacks a description. The description says 'Default true' but does not explain what the parameter controls or why an LLM would set it to false.
Error messages are generic ('Chainlist: no chain matching "X"'). They do not guide the LLM on recovery, e.g., 'Try list_chains() to see available chains' or suggest similar chain names.
Parameter 'chain_id_or_short_name' is overloaded (accepts both numeric ID and string shortName). The description does not clarify the distinction or provide examples of valid formats (e.g., '1' for mainnet, 'eth' for Ethereum).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 55 | 2026-07-28+ | v2 |
list_chains testnet detection uses regex heuristics (/testnet|sepolia|holesky|goerli|mumbai|fuji/i) rather than a canonical 'testnet' field from the chains.json source. This is fragile and may miss or misclassify chains.