Server defines 4 tools with explicit schemas and descriptions. Naming follows verb_noun pattern (oj_*, codeforces_get_*). Descriptions are present (34-128 chars) but lack actionable context for LLM selection. Input schemas are well-formed with Zod validation and JSON Schema export. However, parameter descriptions are entirely absent, LLMs cannot infer what 'nativeId', 'query', 'limit', 'platform', 'requestId', 'schemaVersion' mean without documentation. Output schemas are referenced but not visible in source. Error handling exists (CodeforcesApiError, CodeforcesRequestCancelledError) but recovery guidance is minimal. Tool composition is sound (single responsibility), but parameter naming could be more explicit (e.g., 'problem_id' vs 'nativeId').

• Add parameter descriptions to all tools. For oj_search_problems: document 'query' (search term: problem ID, title, or tag), 'limit' (1-50 results, default 20), 'platform' (always 'codeforces'), 'requestId' (unique request identifier), 'schemaVersion' (API version, always 'oj.search-request/v1'). For codeforces_get_problem_metadata: document 'nativeId' (problem ID in format 158/A, 158A, or 158-A; 2-64 chars).
• Expand tool descriptions to 100-200 chars. Example for oj_search_problems: 'Search Codeforces problem metadata by ID, title, or tag. Returns up to 50 matching problems with difficulty, tags, and acceptance rate. Use this to discover problems before fetching full metadata.'
• Rename 'nativeId' to 'problem_id' for clarity. If the API requires 'nativeId' internally, map it inside the tool implementation.
• Verify and document output schemas. Ensure oj_search_problems returns problem_id, title, difficulty, tags, and acceptance_rate (not verbose API metadata). Ensure codeforces_get_problem_metadata returns all fields needed for downstream analysis.
• Enhance error messages with recovery guidance. Example: 'Problem 999/Z not found. Try searching with oj_search_problems to find valid problem IDs, or check the problem number format (e.g., 158/A).'