Loading ToolBench
MCP Server for LeetCode API (supports leetcode.com and leetcode.cn)
This LeetCode MCP server demonstrates solid definition quality with well-structured tool naming, comprehensive descriptions, and proper schema definitions. All 18 tools follow consistent verb_noun naming conventions (get_, search_, list_, create_, update_, run_, submit_). Descriptions are detailed and contextual, ranging from 150-250 characters, explicitly stating auth requirements, platform availability (Global/CN), and usage guidance. Input schemas are fully defined with Zod validation, including proper enums for constrained inputs (difficulty levels, sort orders, status filters). However, there are meaningful gaps: output schemas are not explicitly documented in the code (tool responses return JSON.stringify without TypeScript type exports), error handling is generic (catch-all error messages without recovery guidance), and some tools lack granular permission/scope declarations. Parameter descriptions are generally strong but could better specify constraints (e.g., timeout bounds, regex patterns for slugs). The server properly accepts human-friendly identifiers (usernames, titleSlugs) alongside system IDs, supporting natural agent interactions.
Creates a new personal note for a problem (write operation, requires auth, CN only). Supports markdown content. Returns { success, note } as JSON. Use update_note to modify an existing note by noteId.
Retrieves today's Daily Challenge problem with full description (read-only, no auth). Returns problem details for the current date as JSON. Use get_problem when you know a specific titleSlug; use search_problems to discover problems by filters.
Retrieves personal notes for a specific problem by questionId (read-only, requires auth, CN only). Use search_notes to find notes across problems by keyword when you don't know the questionId.
Retrieves a single LeetCode problem by titleSlug (read-only, no auth). Returns description, examples, constraints, and metadata as JSON. Use search_problems to find problems by keyword/tag/difficulty; use get_daily_challenge for today's featured problem.
Retrieves full content of a community solution article (read-only, no auth). Requires topicId from list_problem_solutions. Returns article text, author, and metadata as JSON. Use list_problem_solutions first to discover solutions and obtain topicId.
Output schemas not explicitly documented. Tool responses return JSON.stringify() without exported TypeScript types or documented field structures. LLMs cannot reliably predict response structure for downstream chaining.
Error handling is generic and non-actionable. All tools catch errors and return { error, message } without recovery guidance, error categorization (retryable vs user-fixable), or suggestions for next steps. Agents cannot self-correct or adapt.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 68 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 46 | - | v1 |
Retrieves a user's recent submission history on LeetCode Global (read-only, no auth). Includes both accepted and failed submissions. Global only—not available on CN. Use get_recent_ac_submissions for accepted-only results, or get_all_submissions (auth, current user) for paginated full history with filters.
Retrieves a user's contest ranking and participation history (read-only, no auth). Returns overall rating, ranking, and per-contest performance as JSON. Use get_user_profile for general stats and ranking; use this specifically for contest performance data.
Retrieves any user's public profile by username (read-only, no auth). Returns ranking, avatar, bio, submission stats, and platform-specific progress. Use this to look up other users or public stats. Use get_user_status (requires auth) instead to verify the current session user's login state—not for looking up arbitrary users.
Lists community solution articles for a problem (read-only, no auth). Returns metadata only (topicId)—not full content. Use get_problem_solution with the returned topicId to read the full article. Do not call this when you already have a topicId and need the solution text.
Runs code against test cases without submitting (side effect: creates interpret request on LeetCode, requires auth). Polls /check/ until finished; returns start response and final check JSON. Supports custom input via dataInput. Use submit_solution for official judging; use run_code for testing/debugging only.
Searches the authenticated user's personal notes across all problems (read-only, requires auth, CN only). Keyword search with pagination. Use get_note when you know the specific questionId; use this to find notes by keyword across problems.
Searches LeetCode problems by category, tags, difficulty, and keywords (read-only, no auth). Supports pagination via limit/offset. Returns matching problem list as JSON. Use get_problem when you already know the titleSlug; use this to browse or discover problems.
Submits code for official judging (side effect: creates submission on LeetCode, requires auth). Polls /check/ until finished; returns start response and final check JSON. Counts toward submission history. Use run_code for dry-run testing with optional custom input; use submit_solution when ready for final judging.
Updates an existing personal note by noteId (write operation, requires auth, CN only). Use create_note for new notes; use get_note or search_notes first to find the noteId.
No tool annotations present (readOnlyHint, destructiveHint, idempotentHint). While the FEATURES report lists toolAnnotations=false, these annotations are part of the current MCP spec (2026-07-28) and would improve agent planning and safety, especially for write operations (create_note, update_note, run_code, submit_solution).
Missing scope/permission declarations. Tools do not explicitly declare what permissions they require (read:problems, write:notes, write:submissions, etc.). This prevents least-privilege configuration and audit clarity.
Timeout and polling parameters lack explicit bounds. run_code and submit_solution accept timeoutMs and pollIntervalMs without documented min/max values. Agents could pass extreme values causing hangs or excessive API load.
No dry-run or confirmation mechanism for irreversible operations. create_note, update_note, run_code, and submit_solution all have side effects (create submission on LeetCode) but lack a preview/confirm pattern to prevent accidental execution.