Loading ToolBench
MCP Server for RustChain - Query the chain from Claude Code
This server exhibits significant definition quality issues across all five tools. All tools have minimalist descriptions (10-47 characters, well below the 50-200 char baseline for LLM-optimized descriptions). While input schemas are present for 4 of 5 tools, they lack parameter-level descriptions entirely, a critical deficiency per the rubric. The rustchain_bounties tool has an empty inputSchema with no properties, and its handler returns a hardcoded redirect rather than calling an API. No output schemas are documented, making it impossible for LLMs to plan downstream tool usage. Parameter descriptions are absent across all tools, violating the requirement that every parameter needs a description explaining what it controls (see rubric: 'Every parameter needs a description'). Error handling is minimal, tools return raw error messages without recovery guidance. The tool names follow a reasonable verb_noun pattern (rustchain_*), but lack the specificity needed to disambiguate related operations (e.g., 'get_balance' vs 'rustchain_balance'). No tool declares what it returns, and responses are unstructured JSON strings rather than typed objects.
Check RTC balance for any wallet address
List open bounties with rewards
Get current epoch info (slot, height, rewards)
Check node health across all attestation nodes
List active miners and their architectures
All tools lack parameter descriptions. The miner_id parameter in rustchain_balance has no description explaining what constitutes a valid wallet/miner ID, expected format, or whether it accepts addresses, usernames, or opaque IDs.
Tool descriptions are too short and lack context. rustchain_miners (30 chars), rustchain_epoch (32 chars), rustchain_health (38 chars) all fall well below the 50-200 char baseline. They state WHAT the tool does but not WHEN to use it or what it returns.
No output schemas documented. LLMs cannot infer what fields rustchain_balance, rustchain_miners, etc. return, making it impossible to plan follow-up tool calls or extract required IDs for chaining.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 34 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 32 | - | v1 |
rustchain_bounties tool returns a hardcoded string ('Visit https://github.com/...') instead of querying a data source. It has an empty inputSchema with no properties, suggesting it is a stub or redirect rather than a functional tool.
Error handling provides no recovery guidance. When queryNode() throws 'All nodes failed', the handler catches it and returns a generic error message. No indication of whether to retry, whether this is fatal, or what the LLM should do next.
miner_id parameter in rustchain_balance accepts a string with no validation, format constraints, or examples. LLMs cannot determine whether to pass 'john.doe', '0x123...', 'miner_001', or a numeric ID.
Tool responses return raw JSON strings wrapped in {type: 'text'} content blocks rather than structured objects with typed fields. This forces LLMs to parse unstructured text, wasting tokens and increasing hallucination risk.