Loading ToolBench
A Model Context Protocol (MCP) server for Celo blockchain data access and functionality
The Celo MCP server defines 7 blockchain read-only tools with complete JSON schemas and basic descriptions. All tools have names starting with action verbs (get_, call_, estimate_) and structured input parameters with type declarations. However, descriptions are brief (10-30 chars for most), lack context about WHEN to use each tool, and do not explain error recovery. Parameter descriptions are present but minimal. Output schemas are not documented, LLMs cannot plan downstream tool composition without knowing what fields are returned. The server demonstrates foundational quality but falls short of production-grade tool design. All tools are READ_ONLY, which is appropriate for a blockchain data service, but lacks sophistication in parameter validation guidance, dependency documentation, and response shaping.
Fetch detailed information about a specific block on the Celo blockchain using its number or hash. Optionally include full transaction details within the block.
Get CELO and stable token balances for an address.
Get current gas fee data including EIP-1559 fees.
Get Celo governance proposals with pagination support.
Get information about the most recent blocks on the Celo blockchain, with the ability to specify the number of blocks to retrieve and starting offset.
Retrieve the current status and connection information of the Celo network, including network health and connectivity details.
Get detailed information about a specific governance proposal including its content and voting history.
Output schemas not documented. LLMs cannot determine what fields each tool returns, preventing composition of multi-step workflows. For example, get_block_details does not document whether it returns transaction_count, gas_used, gas_limit, or other fields, yet basic_usage.py shows the code expects these fields. Without documented return types, agents cannot chain tools or extract necessary data for downstream calls.
Tool descriptions are too brief (10-30 characters). 'Get comprehensive network status', 'Get detailed block information', 'Get detailed transaction information' fail to explain WHEN to call each tool, what distinguishes them from each other, or how they fit into a blockchain workflow.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 14 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 42 | - | v1 |
Get balances of all major stable tokens and CELO for an address using multicall.
Get the token balance for a specific address.
Obtain detailed information about a specific transaction on the Celo blockchain using its transaction hash.
Parameter descriptions are missing or minimal. For example, call_contract_function accepts 'abi' (Contract ABI) and 'function_args' (Function arguments) with no guidance on format. Is 'abi' a stringified JSON array, a Python list, or an object? What format are 'function_args'? The rubric requires descriptions to state expected format, range, and allowed values. These params violate that requirement, forcing LLMs to guess or fail.
No error handling guidance. All tools are marked READ_ONLY and do not document what errors they can raise (invalid block number, unknown transaction hash, malformed contract address) or how LLMs should recover. Error responses must tell the agent what to do next per the rubric. No recovery patterns are evident.
Parameter validation rules not documented. For example, get_block_details accepts block_identifier as 'integer|string' but does not specify that strings must be either a hex hash (0x...) or the literal 'latest'. Without this constraint in the description, LLMs may pass invalid values like 'most_recent' or 'pending'. Rubric requires format/range/constraint documentation.
Response shaping not evident. No indication that responses are stripped of irrelevant API metadata, paginated appropriately, or capped at reasonable limits. The rubric baseline shows large result sets degrade LLM reasoning, if get_latest_blocks returns 10 full block objects with deep nesting, that wastes tokens. Example code shows use of fields like 'gas_utilization' which may not be present in raw blockchain responses; unclear whether tool handles that transformation.