Loading ToolBench
MCP server for Validation Cloud API integration
The server exposes a single tool 'ethereum_request' with critical definition gaps. The tool name lacks a clear action verb and is overly generic for what is fundamentally a proxy to Ethereum RPC methods. The description (19 characters) is below the minimum viable threshold and provides no context about when to use the tool, what it returns, or what errors might occur. Input schema has no parameter descriptions, 'method' and 'params' are completely undocumented. The params array accepts any items (`"items": {}`), which provides zero guidance to the LLM about valid Ethereum methods or parameter structures. No output schema is documented. Error handling exists in code but is not reflected in tool documentation. The tool violates pattern:tool-description (missing descriptions for parameters), pattern:tool (incomplete schema), and pattern:constrained-input (method should be an enum of valid Ethereum RPC methods).
Make Ethereum JSON-RPC requests using Validation Cloud
Tool name 'ethereum_request' lacks clear action verb and is overly generic. Does not follow verb_noun convention (e.g., 'call_ethereum_rpc', 'execute_eth_method'). LLM cannot disambiguate intent from name alone.
Tool description is 19 characters: 'Make Ethereum JSON-RPC requests using Validation Cloud'. Falls below minimum viable threshold (10-1024 chars per pattern:tool-description). Provides no context on WHAT, WHEN, or what the tool returns. LLM cannot determine when to select this tool over alternatives.
Input parameters 'method' and 'params' have NO descriptions. Per pattern:tool-description, every parameter must have a non-empty description explaining what it controls. LLM cannot infer valid method names (eth_blockNumber, eth_getBalance, etc.) or parameter structures from names alone.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 5 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 17 | - | v1 |
'method' parameter should be an enum of valid Ethereum JSON-RPC methods, not a free-form string. Per pattern:constrained-input, parameters with known value sets must declare enums to prevent hallucinated invalid methods.
'params' array has `"items": {}` with no schema or description. LLM receives zero guidance on parameter structure for different methods (e.g., eth_getBalance expects [address, blockNumber], eth_getLogs expects [filter_object]). Forces trial-and-error.
No output schema documented. Tool returns `{ toolResult: results }` but LLM does not know what 'results' contains, what fields are present, or how to chain downstream tool calls.
Error handling in code (ValidationCloudError catch) is not reflected in tool documentation. Per pattern:recovery-guide, error responses must tell the LLM what to do next, not just return isError=true with a message.