Loading ToolBench
Reduce LLM token costs by 30-60% with TONL format. TypeScript library & CLI with MCP Server for bidirectional JSON/YAML ↔ TONL conversion.
The TONL MCP Bridge exposes 3 tools for JSON↔TONL conversion and token savings calculation. All tools have descriptions and visible input schemas, but quality gaps significantly limit production readiness. Naming is clear and verb-based (convert_, parse_, calculate_), but descriptions are marketing-focused rather than LLM-optimized. Parameter descriptions are present but generic. No output schemas are documented. Error handling guidance is absent. The server lacks tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite being READ_ONLY. No evidence of pagination support, field-level output shaping, or recovery guidance for common failure modes.
Calculate token savings and ROI from TONL compression.
Convert JSON data to TONL format. Reduces token usage by 30-60%.
Parse TONL format back to JSON data.
Tool descriptions lack LLM-optimization guidance. Descriptions are marketing claims ('Reduces token usage by 30-60%') rather than operational guidance (when to call, what it returns, prerequisites, failure modes). Average description length is ~70 chars; baseline is 194 chars (p10=34, p90=392). Missing context on WHEN to use each tool and how they compose.
Output schemas are not documented. The rubric requires documentation of what each tool returns so LLMs can plan downstream calls and extract the right data. No evidence of return types, field names, or structure for convert_to_tonl (presumably returns TONL string?) or calculate_savings (presumably returns cost/ROI breakdown?). This forces LLMs to guess.
Missing tool annotations. All 3 tools are marked risk=READ_ONLY in metadata, but the actual tool definitions lack readOnlyHint annotations in the schema. This is required for current MCP spec (2026-07-28) and helps clients optimize caching and planning.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 57 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 25 | - | v1 |
Parameter descriptions are minimal and lack constraint details. E.g., 'data' param: 'JSON data to convert', does not specify max size, encoding, nesting depth limits, or what happens if data is malformed. 'model' param in calculate_savings lists no valid enum values (gpt-4, gpt-3.5-turbo, claude-3-opus, etc.). LLMs cannot validate inputs without explicit constraints.
No error handling guidance. If convert_to_tonl fails on invalid JSON or oversized payload, what should the LLM do? Is it retryable? User-fixable? Should it fall back to standard format? No recovery paths documented. Baseline pattern: error responses must tell the LLM what to do next.
Missing parameter relationships documentation. convert_to_tonl accepts 'data' (object|array), does the schema mean it accepts EITHER an object OR an array, or BOTH? If both, does structure affect compression ratio? No guidance on when to use parse_tonl (reverse operation of convert_to_tonl?) vs standalone.