Loading ToolBench
MCP server for Blockscout blockchain data platform, enabling access to blockchain analysis, smart contract inspection, transaction history, and token information across multiple chains
Blockscout MCP server demonstrates solid definition quality with consistent naming patterns, complete parameter schemas, and strong tool composition. All 16 tools follow verb_noun naming conventions (get_, lookup_, nft_, inspect_, read_, etc.). Tool descriptions are present and contextually relevant (avg ~120 chars, within the 10-1024 range). All tools expose complete input schemas with parameter descriptions. However, output schemas are not explicitly documented in the provided source, and some descriptions lack clarity about when to use a tool vs similar alternatives. Error handling guidance is minimal, descriptions do not explain recovery paths or categorize errors. The server implements reasonable design with clear tool separation and no multi-responsibility tools. Parameter naming is consistent (chain_id, address, session_id) and enables easy chaining between tools. The __unlock_blockchain_analysis__ tool is unusual but appears to be informational. Overall, this is a well-structured blockchain query server that follows production patterns, though output documentation and error guidance could be stronger.
Unlock blockchain analysis features and provide instructions for advanced analysis
Make a direct call to the Blockscout API with custom endpoint paths and parameters
Resolve an ENS (Ethereum Name Service) domain name to a blockchain address
Retrieve comprehensive information about a blockchain address including balance, transaction count, token holdings, and other metadata
Retrieve detailed information about a specific block including transactions, timestamp, and miner details
Get the current block number or block number at a specific datetime
Retrieve a list of all supported blockchain chains
Output schemas not explicitly documented in tool definitions. While input schemas are complete with types and descriptions, return value structures are not formally specified. LLMs cannot reliably plan downstream tool calls or know which fields to extract without documented output schemas.
No error handling or recovery guidance in tool descriptions. Descriptions state WHAT tools do but not WHEN they fail or how the LLM should recover. E.g., 'get_address_info' does not document what happens if the address is invalid, malformed, or does not exist on the specified chain.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 60 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 33 | - | v1 |
Retrieve the ABI (Application Binary Interface) for a smart contract
Retrieve token transfer history for a specific address across a time range
Get a list of tokens held by a specific address
Retrieve detailed information about a specific transaction
Retrieve transaction history for a specific address across a time range
Analyze and inspect the source code and bytecode of a smart contract
Search for tokens by their symbol on a specific blockchain
Retrieve NFT tokens held by a specific address
Execute a read-only smart contract function (view/pure) and retrieve the result
direct_api_call tool has an overly generic name and vague description. 'Make a direct call to the Blockscout API' does not clarify WHEN to use this vs the specialized tools. LLMs may prefer the low-level escape hatch over properly-named, discoverable tools, defeating the purpose of tool decomposition.
__unlock_blockchain_analysis__ tool has an unconventional name (starts with double underscore, unclear purpose). Tool names should be verb_noun (e.g., 'unlock_blockchain_features' or 'get_blockchain_analysis_guide'). The current name is ambiguous and does not convey action to the LLM.
Pagination parameters (age_from, age_to, cursor) are present in some tools but not others. Consistency in pagination support and documentation would help LLMs understand how to iterate over large result sets. Tools like get_token_transfers_by_address and get_transactions_by_address support pagination, but the description does not clarify whether results are limited or if cursor is required for large datasets.
session_id parameter is marked 'Optional' in descriptions, but the purpose and lifecycle of session IDs are not explained. LLMs cannot determine when to pass a session_id or how it affects rate limiting and caching behavior. The config shows BLOCKSCOUT_SESSION_TTL_SECONDS=900 and per-session call limits, but this is not documented in tool descriptions.