All 4 tools have basic descriptions and input schemas with type definitions, but quality is significantly below production standards. Descriptions are minimal (10-80 chars, well below the 194-char baseline) and lack context for LLM selection. Parameters lack descriptions entirely in most cases. Output schemas are completely undocumented, LLMs cannot plan downstream calls or extract structured data. No error handling guidance, no parameter constraints (enums), and no indication of what fields are returned. Tool names are acceptable (verb_noun pattern) but descriptions fail to explain WHEN to use each tool or what distinguishes them.

• Add output schema documentation for each tool. Example for get_user_info: 'Returns object with fields: handle (string), firstName (string), lastName (string), rating (integer), maxRating (integer), rank (string), maxRank (string), organization (string), contribution (integer).'
• Expand tool descriptions to 100 - 200 chars explaining WHAT, WHEN, and WHAT DISTINGUISHES from similar tools. Example: 'Get current and historical rating changes for a user. Use this to track rating progression over time. Returns a list of rating updates with old/new values and timestamps. Differs from get_user_info which returns static profile data.'
• Add descriptions to all parameters. For 'handle': 'Codeforces username (case-insensitive, 1-50 alphanumeric characters).' For 'contest_type': 'Filter contests by type. Use gym for practice contests, contest for official competitions, or None for all.'
• Replace free-form contest_type string with enum constraint in schema: {"type": "string", "enum": ["gym", "contest", "None"], "description": "Contest type filter..."}
• Enhance error messages with recovery guidance. Instead of returning raw exception, catch and return: 'User not found. Verify the handle is spelled correctly (case-insensitive). Try search_users() if unsure of the exact name.' or 'Request timeout (30s). The Codeforces API may be overloaded. Retry in 5 seconds.'