Loading ToolBench
The server defines 24 tools with basic schemas and descriptions, but exhibits significant quality gaps. All tools have descriptions (positive) and input schemas (positive), but descriptions are often generic (10-50 chars) rather than LLM-optimized (50-200 char baseline). Parameters lack depth: many lack validation guidance (ranges, format constraints, enums). No output schemas documented. No error handling guidance visible. Tool composition issues: multiple tools performing similar operations (e.g., get_address_balance vs get_address_balance_from_node) without clear distinction in naming or descriptions. The server is READ_ONLY and STDIO-based, which limits risk, but definition quality remains below production baseline.
Analyze an Ergo address with comprehensive information.
Analyze a smart contract on the Ergo blockchain.
Analyze a transaction on the Ergo blockchain.
Analyze a transaction from the local Ergo node.
Get the confirmed balance for an Ergo address.
Get address balance at specific height.
Get the confirmed balance for an address directly from the node.
Duplicate tool definitions with confusing naming: 'get_address_balance' vs 'get_address_balance_from_node', 'analyze_transaction' vs 'analyze_transaction_from_node', etc. The distinction (API-sourced vs node-sourced) is not clear in names and descriptions, forcing LLMs to reason about which variant to call.
Descriptions lack contextual depth. Most descriptions are 15-60 characters and do not answer WHEN to use a tool or WHAT it returns. Pattern baseline is 50-200 chars. Example: 'Get the current network state and status' (47 chars) does not explain what 'state and status' means, what data structure is returned, or when to call this vs other status tools.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 36 | - | v1 |
Get balance history for an address.
Get rank of a P2PK address in terms of balance.
Get statistics about smart contracts on the network.
Get contract address count and supply held in contract addresses.
Get list of tracked exchange addresses.
Get liquidity pools information, optionally filtered by token.
Get the current network state and status.
Get network information directly from the node.
Get rich list of addresses sorted by balance.
Get historical price data for a token.
Get the current price of a token in ERG and USD.
Get information about token swaps and exchange rates.
Get transaction history for an address.
Get transactions for an address from the local node.
Search for tokens by ID or symbol.
Search for tokens on the node.
Simulate the execution of a smart contract.
No output schemas documented in source or README. Tool descriptions do not specify what fields or structure is returned. LLMs cannot plan downstream operations without knowing the response schema. Pattern requires documenting return types for all tools.
Parameters lack validation constraints and format guidance. Descriptions do not specify ranges, enums, regex patterns, or format expectations. Example: 'days' parameter in get_token_price_chart has no guidance on valid range (1 - 365? 1 - 10000?). LLMs will guess and pass invalid values.
No error handling guidance. Code contains try/except blocks that return generic error strings (e.g., 'Error fetching balance: <str(e)>'). Errors do not categorize failures as retryable, user-fixable, or fatal, nor do they suggest recovery actions. Pattern requires actionable error messages.
Tools lack composition clarity. No clear mapping of output fields to input parameters of related tools. Example: get_address_balance returns balance data, but the response structure is not documented, so an LLM cannot reliably pass fields to analyze_address or other downstream tools.
No pagination guidance in tool descriptions. Paginated results (get_rich_list, get_transaction_history) accept limit/offset but descriptions do not state default limits, maximum page sizes, or expected return counts. Pattern requires pagination guidance to prevent context window exhaustion.