Three tools with complete input schemas and descriptions, but quality is uneven. Tool names follow verb_noun pattern (convert_to_tonl, parse_tonl, calculate_savings). Descriptions are present (40-80 chars) but lack depth on WHEN to use each tool and what downstream operations they enable. Parameter descriptions exist but are minimal (15-40 chars). No output schemas documented, LLMs cannot plan chained calls or extract specific fields. No error handling guidance. Missing idempotency hints for stateless operations. Tool composition is reasonable (three distinct concerns), but descriptions don't explain dependencies or typical workflows.

• Document output schemas for all three tools. E.g., convert_to_tonl returns {tonl_data: string, original_tokens: number, compressed_tokens: number, savings_percent: number}. This enables LLMs to chain calls and extract ROI metrics.
• Expand tool descriptions to 100-150 chars explaining WHEN to use each. E.g., 'Use convert_to_tonl to compress JSON/YAML before sending to an LLM. Reduces token cost by 30-60%. Call parse_tonl to decompress the result.'
• Add min/max constraints to numeric parameters. E.g., queriesPerDay: 1-100000, originalTokens: 1-1000000. Include guidance: 'Typical daily queries: 100-10000 for small apps, 10000-100000 for production services.'
• Add error handling guidance to descriptions. E.g., 'If JSON parsing fails, the tool returns {error: string, suggestion: string}. Ask the user to validate the JSON format.'
• Document idempotency: 'Calling convert_to_tonl twice with the same input produces identical output. Safe to retry on transient failures.'