Loading ToolBench
High-performance CLI proxy to minimize LLM token consumption through intelligent output filtering and compression
Mycelium exposes only 2 tools via STDIO-only MCP. PING has a trivial description (11 chars, below 20-char threshold). mycelium_gain has a reasonable description (77 chars) and a well-structured input schema with 8 parameters, each with type and description. However, neither tool documents output schemas, critical for LLM planning. PING's description is too short to guide tool selection. No error handling guidance, no recovery hints, no idempotent/destructive annotations. Tool composition is minimal (only 2 tools). The server lacks pagination, result limits, and field-level documentation for responses.
Health probe, returns empty object
Token savings query; params mirror the gain --format json flags
PING description is 11 characters ('Health probe, returns empty object'), below 20-char minimum. Too short to guide LLM tool selection. Expand to explain when/why to call it.
No output schemas documented for either tool. LLMs cannot plan downstream calls or extract required fields. PING returns '{}' but mycelium_gain's response structure is undocumented.
mycelium_gain lacks error handling guidance. If tracker init fails or query fails, the tool returns {'error': '...'} but does not tell the LLM what to do next (retry, ask user, abort).
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Both tools are read-only but this is not declared in the schema, forcing LLMs to infer safety from descriptions.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 45 | <=2025-11-25 | v2 |
mycelium_gain accepts 'limit' (default 10) but does not document pagination or total count. Large result sets could exhaust context; no guidance on how to fetch next page.