Loading ToolBench
MCP server for making JSON-RPC calls to Ethereum networks, with special support for Zircuit chain-specific methods
This server has critical gaps in definition quality. While all three tools are explicitly registered with schemas, the descriptions are either trivial or incomplete, parameter descriptions lack depth, and output schemas are completely undocumented. The tool names follow basic verb conventions but lack clarity for LLM reasoning. Error handling exists but is generic (no recovery guidance). The overall approach prioritizes pass-through to Ethereum RPC rather than building useful abstractions.
Parameters: - method (string, REQUIRED): The JSON-RPC method to execute. - params (array, REQUIRED): The parameters for the JSON-RPC method.
Using zirc_getQuarantined, you can also query all quarantined transactions and filter them by addresses.
zirc_isQuarantined takes a transaction hash as a parameter and outputs the quarantine status of the transaction
NO OUTPUT SCHEMAS DOCUMENTED. All three tools are completely silent on what they return. LLMs cannot plan chaining, extract downstream values, or validate responses. The implementations return 'content: [{type: "text", text: JSON.stringify(result)}]' but this unstructured text response tells the agent nothing about structure, fields, or data types.
DESCRIPTIONS ARE TOO SHORT AND MECHANICAL. Descriptions range from 67 - 120 chars (baseline 194) and read like API reference documentation rather than LLM-optimized guidance. They list parameters but do not answer: When should the LLM choose this tool? What does it do in plain terms? What are the common failure modes and how to recover? This violates the 'prompt-engineering' principle.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 30 | - | v1 |
eth_json_rpc_call ACCEPTS PARAMS AS ARRAY OF STRINGS. This is dangerously under-specified. JSON-RPC methods expect heterogeneous parameters (addresses, numbers, booleans, arrays). Forcing them into 'array of strings' means the LLM must construct valid JSON stringified parameters, introducing type-mismatch errors. Example: 'eth_getBalance' expects [address, blockTag] where blockTag is NOT a string literal but either 'latest' or a hex number, the schema does not capture this.
MISSING PARAMETER DESCRIPTIONS. The 'method' parameter in eth_json_rpc_call has a description, but there is no guidance on WHICH methods are supported, what constraints exist (e.g., 'only read-only eth_* and net_* methods'), or what happens when an unsupported method is passed. The zirc_* tools mark the address parameter as optional but do not explain the behavioral difference (does empty address mean 'all addresses'? or is it an error?).
ERROR HANDLING IS GENERIC AND NON-ACTIONABLE. All three tools catch errors and return 'Error executing RPC call: {error.message}'. This tells the LLM nothing. No recovery guidance (should it retry? call a different tool? ask the user?). No error classification (retryable vs fatal). No examples of what might fail (invalid method, network timeout, rate limit, malformed params). An LLM seeing 'Error: Invalid params' has no next step.
NO TOOL NAMING FOLLOWS VERB_NOUN PATTERN. eth_json_rpc_call is method-centric ('call'), not action-centric. zirc_isQuarantined and zirc_getQuarantined are RPC-method mirrors, not agent-oriented names. Better names: 'execute_rpc_method', 'check_transaction_quarantine_status', 'list_quarantined_transactions'. Current names do not clearly signal intent to an LLM choosing between tools.
ZIRC_* TOOLS ONLY CONDITIONALLY REGISTERED. zirc_isQuarantined and zirc_getQuarantined are only added if chainId === 48900 (Zircuit). The server code does not document this discovery mechanism. An LLM interacting with a non-Zircuit RPC will not see these tools and cannot reason about why. If tools are domain-specific, the server should document this and provide clear error messages when tools are unavailable.