Loading ToolBench
MCP server for querying Ethereum validator activation and exit queue statistics
ETH Validator Queue has weak definition quality across multiple dimensions. Tool names are appropriately action-verbs (get_*), and descriptions exist for all tools and parameters. However, descriptions are excessively verbose (300+ chars when best practice is 50-200), lack structured output documentation, contain unvalidated assumptions about API behavior, and provide no error guidance. Input schemas are minimal or missing validation constraints. The server returns unstructured plain-text responses rather than structured JSON objects, forcing LLMs to parse free-form strings. No parameter validation, no pagination support, no output field documentation, and error messages are generic catch-all handlers that give agents no recovery path.
Get current Ethereum validator activation queue statistics. Returns: A string containing: - Current activation queue length (number of validators waiting to activate) - Total active validators - Total balance of entering validators in ETH - Estimated wait time (based on ~900 activations per day)
Get current Ethereum validator exit queue statistics. Returns: A string containing: - Current exit queue length (number of validators waiting to exit) - Total active validators - Total balance of exiting validators in ETH - Estimated wait time (based on ~900 exits per day)
Get status for a specific Ethereum validator by public key. Args: pubkey (str): The public key of the validator (48-byte hex string starting with '0x') Returns: A string containing: - Validator public key - Current status (e.g., active_online, pending, exited) - Effective balance in ETH - Activation epoch (if applicable) - Exit epoch (if applicable)
No input schemas provided for get_activation_queue and get_exit_queue. Tools accept no parameters but schema field is {}.
get_validator_status accepts pubkey parameter but provides NO validation constraints. Description says '48-byte hex string starting with 0x' but does not enforce this via regex pattern, length constraints, or enum. LLMs will pass arbitrary strings and fail silently.
All tools return unstructured plain-text strings. Output schemas are not documented. LLMs cannot extract specific fields (queue_length, wait_time_days, balance_eth) programmatically and must parse free-form text. This violates pattern:response-shaper and increases hallucination risk.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 37 | 2026-07-28+ | v2 |
Error handling is a bare catch-all that returns 'Error fetching X data: {str(e)}'. No recovery guidance. LLMs cannot determine if the error is retryable, user-fixable, or fatal.
Descriptions are excessively verbose (300-350+ chars) and include return value lists as if documenting return type, not usage guidance. Verbose docstrings waste tokens and bury key selection criteria.
No parameter descriptions provided for pubkey in get_validator_status input schema. Currently schema shows only {"type": "string", "description": "..."}. While description is present in the method docstring, it is not in the schema object passed to the tool registration.
Tool assumes fixed rate of ~900 activations/exits per day without documenting this assumption or providing guidance on variance. LLMs will use outdated estimates if network conditions change. Should include confidence level or link to dynamic rate data.
Division by zero risk: if exiting or entering count is 0, code calculates wait time as 0.0 days (safe) but does not handle edge case where denominator might be zero in future. More critically, no validation that API response structure matches expectations.