The LeetCode MCP server provides 7 tools with reasonable naming conventions (all verb-prefixed: get-*, search-*) and consistent parameter schemas using Zod. However, tool descriptions are universally too brief (7-20 characters), falling below the 34-character minimum baseline for quality tools. Parameter descriptions are present and mostly clear, but output schemas are completely undocumented, responses are returned as raw JSON without formal schema declaration. Error handling is present but generic ('Error: <message>'), lacking actionable recovery guidance. The server implements all tools with Zod validation and explicit error try-catch blocks, which is good, but descriptions fail to meet the 10-1024 character requirement and do not explain WHEN to use each tool or what field names appear in responses.

• Expand all tool descriptions to 50-150 characters explaining WHAT the tool does, WHEN to use it, and what it returns. Example: 'Get contest details for a LeetCode contest. Use this to view contest meta-data (title, start_time, end_time, participant_count). Returns contest object with schedule and rules.'
• Document all output schemas formally. Add a 'Returns' section to each tool description listing the top-level fields (e.g., 'Returns: { contest_id: string, title: string, start_time: ISO8601, end_time: ISO8601, problems: Problem[] }'). This enables LLMs to plan downstream tool calls.
• Improve error handling to categorize failures: For 'not found' errors, return 'User not found. Use search-problems or get-user-profile with a different username.' For network errors, return 'API timeout (retryable). Please try again.' Provide recovery steps, not raw exception text.
• Add tool annotations via the MCP SDK. All tools should declare readOnlyHint=true in their metadata, signaling to clients that these are safe, idempotent operations. See the mcp-sdk tool registration API for how to attach annotations.
• Enhance search-problems description to explain pagination: 'Search LeetCode problems by tags and difficulty. Returns up to `limit` (default 20) problems starting at offset `skip`. Use skip for pagination. Tag format: separate multiple tags with "+" (e.g., "array+dynamic-programming"). Returns total count to enable client-side pagination UI.'
• Consider adding a 'list-problem-tags' or 'list-problem-difficulties' discovery tool to help agents understand valid filter values without trial-and-error.