All 4 tools have clear, action-verb names (get_*, check_*) and reasonable descriptions (80-120 chars). However, ALL tools declare empty input schemas ({}) with zero parameters, violating the critical rule that every parameter needs a description. The descriptions themselves, while present, lack actionable detail about prerequisites, error conditions, or what data is returned. No output schemas are documented. Error handling exists in code (isError flag, fallback messages) but is not reflected in tool definitions. The server reads OAuth tokens from environment/credentials, good security practice, but this dependency is not documented in tool descriptions.

• Add explicit input schemas to all tools. Even if no parameters are needed, declare an empty object with a description: 'This tool requires no parameters. It uses your OAuth token from the Claude Code environment.'
• Expand tool descriptions to 80-150 chars. Include: (1) what data is returned, (2) when to call it vs. similar tools, (3) what happens if OAuth token is missing/expired. Example: 'Get your current 5-hour session usage window. Requires valid OAuth token from Claude Code. Returns burst limit used, reset time, and status. If token is missing, returns cached data with a warning.'
• Document output schemas in tool definitions. Specify the structure of formatFullUsage, formatSessionUsage, formatWeeklyLimits, and formatRateStatus outputs (e.g., fields, types, example values).
• Add error classification to tool descriptions. State: 'Errors are retryable (network timeout, rate limit 429) or user-fixable (missing OAuth token, expired credentials). Stale cache is returned on network failure.'
• Consider adding a discovery tool (e.g., 'get_usage_info') that returns available metrics and their meanings, helping LLMs understand the domain before calling specific tools.