Loading ToolBench
Read-only monitor for a NerdOS solo miner. Exposes four read-only tools over the stdio transport to query miner status, pool statistics, hardware health, and device information.
All four tools have good descriptions (50-200 chars, well-written), but critically lack input schemas. Tools accept no parameters (empty {} input), which is unusual for a monitoring server and limits flexibility. No parameter descriptions exist because there are no parameters. Error handling is present (fetch_system_info returns human-readable strings on failure), but tools do not guide recovery or categorize errors. Output is unstructured text rather than JSON objects, forcing LLMs to parse free-form strings. No tool annotations (readOnlyHint, etc.). Naming is clear and verb-based (get_*), following conventions. Overall: descriptions are strong, but schema absence and unstructured output are critical gaps.
Return device identity, firmware version and uptime. Covers the device and ASIC model, hostname, firmware version, uptime, the last reset reason and free heap memory.
Return thermal and electrical detail with derived efficiency. Covers ASIC and voltage regulator temperature against the overheat limit, fan, ASIC frequency, core voltage (set vs actual), power draw, and the derived energy efficiency in joules per terahash.
Return an at-a-glance health overview of the miner. Covers current hashrate (with the 1-hour average), ASIC and voltage regulator temperature, power draw, fan and uptime.
Return the pool connection and share statistics. Covers the active pool, accepted/rejected shares with the reject rate, the best share found (all-time and this session) against the network difficulty, and blocks found — the solo-mining picture.
All tools have empty input schemas ({}). Limits tool flexibility and forces agents to fetch full data and parse locally.
All tools return unstructured plain-text strings instead of structured JSON objects. Free-text responses require the LLM to parse unstructured output, which is error-prone and wastes tokens.' LLMs must regex-parse output like 'Hashrate: 123.4 GH/s' instead of receiving {hashrate_ghs: 123.4}. Increases hallucination risk and token waste.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Per spec 2026-07-28, tool annotations are a current pattern. All four tools are read-only and idempotent, annotating them would help clients optimize caching and retry logic.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 41 | <=2025-11-25 | v2 |
Error handling returns human-readable strings but does not categorize errors as retryable, user-fixable, or fatal. LLMs cannot infer the right recovery action.
No output schema documentation. LLMs need to know what fields to expect so they can plan downstream tool calls and extract the right data.' Tools return free-form text; no schema tells LLMs what to expect or how to extract structured data.