Loading ToolBench
MCP server for blockchain exploration providing chain information, account data, transaction status, fee estimation, and token holder analytics
This server has significant quality gaps across all dimensions. Tool definitions lack proper parameter type annotations in the schema (visible only as Python type hints, not in JSON Schema format). Descriptions are minimal and lack LLM-optimization guidance. Output schemas are undocumented. Error handling is absent. The codebase shows FastMCP usage but schemas are not properly formalized for agent reasoning. Only 5 tools total, all read-only (except top_holders which has WRITE risk but lacks proper validation).
Get account information including native balance and ERC20 token balances for a given address
Get current blockchain chain information including latest block number, hash, gas used, and difficulty
Get current gas fee estimates including base fee and priority fee for EIP-1559 transactions
Get top token holders for a given ERC20 token from a list of addresses
Get transaction status and receipt information for a given transaction hash
Output schemas not documented. No LLM has visibility into what chain_info, account_info, tx_status, fee_estimate, or top_holders return. Agents cannot plan downstream tool calls or extract required fields.
Input schemas lack proper JSON Schema formalization. Parameters exist as Python type hints (e.g., 'address: str', 'tokens: list') but are not formally exposed with JSON Schema types, descriptions, or constraints. The MCP protocol requires explicit schema definitions with 'type' and 'description' for each parameter.
Parameter descriptions missing or inadequate. 'address' in account_info is described only as 'Ethereum address to query', no format constraint (does it require '0x' prefix?), no validation rules, no guidance on what happens with invalid addresses. 'tokens' array lacks description of what token addresses should be (ERC20 contract addresses? ticker symbols?). 'top_n' default is 10 but no min/max bounds specified.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 45 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 30 | - | v1 |
No error handling or recovery guidance. If a transaction hash is invalid, tx_status returns {'status': 'unknown', 'receipt': None} with no hint for the LLM on what to do next (should it retry? ask user? search for similar txs?). account_info silently skips failed token lookups ('except Exception: continue'), agent has no signal that a token query failed.
Descriptions are too brief (under 60 chars for most tools), violating baseline of 194 chars avg and the 10-1024 char requirement. chain_info (52 chars), fee_estimate (64 chars), tx_status (54 chars) fail to state WHEN to use each tool or what makes them distinct from similar lookups.
top_holders has WRITE risk (per spec) but lacks validation, confirmation step, or dry-run option. The tool calls save_analytics_result() which persists data to Supabase, yet there is no pattern:confirmation-request, no audit trail, and no permission check. An agent could inadvertently spam the analytics table.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). The spec requires tools to declare their risk profile. chain_info, account_info, tx_status, fee_estimate are marked as READ_ONLY but fastmcp does not expose this in the tool definition schema. top_holders is WRITE but has no destructive annotation.
No response field documentation for chaining. If an LLM calls account_info and then needs to call top_holders, it must know account_info returns an 'address' field. Without documented response schemas, the LLM has no way to extract the right ID. This forces discovery detours.
Unbounded list parameters. account_info accepts a 'tokens' array with no documented max length. top_holders accepts 'addresses' array with no max. An agent could pass 1000s of addresses, causing timeout or out-of-memory errors with no guidance on limits.