Skip to main content
Glama
shubhamgupta2702

LeetCode MCP Server

by shubhamgupta2702
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

LeetCode MCP Server

NPM Version Chinese Doc NPM Downloads GitHub License LeetCode MCP Server on Glama Stars

The LeetCode MCP Server is a Model Context Protocol (MCP) server that provides seamless integration with LeetCode APIs, enabling advanced automation and intelligent interaction with LeetCode's programming problems, contests, solutions, and user data.

Features

  • 🌐 Multi-site Support: Support​ both leetcode.com (Global) and leetcode.cn (China) platforms

  • 🔌 Dual Transport Modes: Run as a stdio process (default) or as a Streamable HTTP server for web-based integrations

  • 📊 Problem Data Retrieval: Obtain detailed problem descriptions, constraints, examples, official editorials, and ​user-submitted solutions

  • 👤 User Data Access: Retrieve user profiles, submission history, and contest performance

  • 🔒 ​Private Data Access: Create and query user notes, track problem-solving progress, and analyze submission details (AC/WA analysis)

  • 🔍 Advanced Search Capabilities: Filter problems by tags, difficulty levels, categories, and keywords

  • 📅 Daily Challenge Access: Easily access daily challenge problems

Related MCP server: Interactive LeetCode MCP

Prerequisites

  1. Node.js (v20.x or above)

  2. (Optional) LeetCode session cookie for authenticated API access

Installation

# Install from npm
npm install @jinzcdev/leetcode-mcp-server -g

# Run with Global site configuration (stdio transport, default)
npx -y @jinzcdev/leetcode-mcp-server --site global

# Run with authentication (for accessing private data)
npx -y @jinzcdev/leetcode-mcp-server --site global --session <YOUR_LEETCODE_SESSION_COOKIE>

# Run as a Streamable HTTP server
npx -y @jinzcdev/leetcode-mcp-server --transport http --port 3000 --site global

Alternatively, you can clone the repository and run it locally:

# Clone the repository
git clone https://github.com/jinzcdev/leetcode-mcp-server.git

# Navigate to the project directory
cd leetcode-mcp-server

# Build the project
npm install && npm run build

# Run the server (stdio transport)
node build/index.js --site global

# Or run as a Streamable HTTP server
node build/index.js --transport http --port 3000 --site global

Usage

The server supports two transport modes:

Transport

Description

stdio (default)

Standard input/output transport for local MCP clients

http

Streamable HTTP transport for web-based integrations and remote access

Command-Line Options

Option

Alias

Default

Description

--site

-s

global

LeetCode API site: global (leetcode.com) or cn (leetcode.cn)

--session

-c

—

LeetCode session cookie for authenticated requests

--transport

-t

stdio

Transport mode: stdio or http

--port

—

3000

HTTP server port (Streamable HTTP only)

--host

—

127.0.0.1

HTTP server host (Streamable HTTP only)

--endpoint

—

/mcp

HTTP endpoint path (Streamable HTTP only)

MCP Client Configuration (stdio)

Add the following server entry to your MCP client configuration file:

Option 1: Using Environment Variables

{
  "mcpServers": {
    "leetcode": {
      "command": "npx",
      "args": ["-y", "@jinzcdev/leetcode-mcp-server"],
      "env": {
        "LEETCODE_SITE": "global",
        "LEETCODE_SESSION": "<YOUR_LEETCODE_SESSION_COOKIE>"
      }
    }
  }
}

Option 2: Using Command Line Arguments

{
  "mcpServers": {
    "leetcode": {
      "command": "npx",
      "args": [
        "-y",
        "@jinzcdev/leetcode-mcp-server",
        "--site",
        "global",
        "--session",
        "<YOUR_LEETCODE_SESSION_COOKIE>"
      ]
    }
  }
}

For LeetCode China site, modify the --site parameter to cn.

NOTE

The exact configuration file location and JSON structure may vary by MCP client. Some clients use an mcp.servers wrapper or a type field — refer to your client's documentation and adapt the example accordingly.

MCP Client Configuration (Streamable HTTP)

First, start the server in HTTP mode:

npx -y @jinzcdev/leetcode-mcp-server --transport http --port 3000 --site global

Then connect your MCP client to the running server:

{
  "mcpServers": {
    "leetcode": {
      "type": "http",
      "url": "http://127.0.0.1:3000/mcp"
    }
  }
}

To use authenticated endpoints, pass the session cookie when starting the server:

npx -y @jinzcdev/leetcode-mcp-server --transport http --port 3000 --site global --session <YOUR_LEETCODE_SESSION_COOKIE>
NOTE

Some MCP clients use"type": "http" or "type": "streamableHttp" alongside the url field. Refer to your client's documentation for the exact HTTP transport configuration format.

TIP

The server supports the following optional environment variables:

  • LEETCODE_SITE: LeetCode API endpoint (global or cn, default: global)

  • LEETCODE_SESSION: LeetCode session cookie for authenticated API access (default: empty)

  • LEETCODE_TRANSPORT: Transport mode (stdio or http, default: stdio)

  • LEETCODE_HTTP_PORT: HTTP server port when using Streamable HTTP (default: 3000)

  • LEETCODE_HTTP_HOST: HTTP server host when using Streamable HTTP (default: 127.0.0.1)

  • LEETCODE_HTTP_ENDPOINT: HTTP endpoint path when using Streamable HTTP (default: /mcp)

Priority Note: Command-line arguments take precedence over environment variables when both are specified. For example:

  • If LEETCODE_SITE=cn is set but you run leetcode-mcp-server --site global, the server will use global.

  • If LEETCODE_SESSION exists but you provide --session "new_cookie", the command-line session value will be used.

Available Tools

Problems

Tool

Global

CN

Auth Required

Description

get_daily_challenge

✅

✅

❌

Retrieves today's LeetCode Daily Challenge problem

get_problem

✅

✅

❌

Retrieves details for a specific LeetCode problem

search_problems

✅

✅

❌

Searches for LeetCode problems with multiple filter criteria

Users

Tool

Global

CN

Auth Required

Description

get_user_profile

✅

✅

❌

Retrieves profile information for a LeetCode user

get_user_contest_ranking

✅

✅

❌

Obtains contest ranking statistics for a user

get_recent_ac_submissions

✅

✅

❌

Retrieves a user's recent accepted submissions

get_recent_submissions

✅

❌

❌

Retrieves a user's recent submissions history

get_user_status

✅

✅

✅

Retrieves current user's current status

get_problem_submission_report

✅

✅

✅

Provides detailed submission analysis for a specific problem

get_problem_progress

✅

✅

✅

Retrieves current user's problem-solving progress

get_all_submissions

✅

✅

✅

Retrieves current user's submission history

Submissions

Tool

Global

CN

Auth Required

Description

run_code

✅

✅

✅

Runs code for a problem and polls /check/ until finished

submit_solution

✅

✅

✅

Submits code for a problem and polls /check/ until finished

Notes

Tool

Global

CN

Auth Required

Description

search_notes

❌

✅

✅

Searches for user notes with filtering options

get_note

❌

✅

✅

Retrieves notes for a specific problem by question ID

create_note

❌

✅

✅

Creates a new note for a specific problem

update_note

❌

✅

✅

Updates an existing note with new content

Solutions

Tool

Global

CN

Auth Required

Description

list_problem_solutions

✅

✅

❌

Retrieves a list of community solutions for a specific problem

get_problem_solution

✅

✅

❌

Retrieves the complete content of a specific solution

Tool Parameters

Problems

  • get_daily_challenge - Retrieves today's LeetCode Daily Challenge problem with complete details

    • No parameters required

  • get_problem - Retrieves details about a specific LeetCode problem

    • titleSlug: The URL slug/identifier of the problem (string, required)

  • search_problems - Searches for LeetCode problems based on multiple filter criteria

    • category: Problem category filter (string, optional, default: "all-code-essentials")

    • tags: List of topic tags to filter problems by (string[], optional)

    • difficulty: Problem difficulty level filter (enum: "EASY", "MEDIUM", "HARD", optional)

    • searchKeywords: Keywords to search in problem titles and descriptions (string, optional)

    • limit: Maximum number of problems to return (number, optional, default: 10)

    • offset: Number of problems to skip (number, optional)

Users

  • get_user_profile - Retrieves profile information about a LeetCode user

    • username: LeetCode username (string, required)

  • get_user_contest_ranking - Retrieves a user's contest ranking information

    • username: LeetCode username (string, required)

    • attended: Whether to include only the contests the user has participated in (boolean, optional, default: true)

  • get_recent_submissions - Retrieves a user's recent submissions on LeetCode Global

    • username: LeetCode username (string, required)

    • limit: Maximum number of submissions to return (number, optional, default: 10)

  • get_recent_ac_submissions - Retrieves a user's recent accepted submissions

    • username: LeetCode username (string, required)

    • limit: Maximum number of submissions to return (number, optional, default: 10)

  • get_user_status - Retrieves the current user's status

    • No parameters required

  • get_problem_submission_report - Retrieves detailed information about a specific submission

    • id: The numerical submission ID (number, required)

  • get_problem_progress - Retrieves the current user's problem-solving progress

    • offset: Number of questions to skip (number, optional, default: 0)

    • limit: Maximum number of questions to return (number, optional, default: 100)

    • questionStatus: Filter by question status (enum: "ATTEMPTED", "SOLVED", optional)

    • difficulty: Filter by difficulty levels (string[], optional)

  • get_all_submissions - Retrieves paginated list of user's submissions

    • limit: Maximum number of submissions to return (number, default: 20)

    • offset: Number of submissions to skip (number, default: 0)

    • questionSlug: Optional problem identifier (string, optional)

    • lang: Programming language filter (string, optional, CN only)

    • status: Submission status filter (enum: "AC", "WA", optional, CN only)

    • lastKey: Pagination token for retrieving next page (string, optional, CN only)

Submissions

  • run_code - Runs code for a specific problem and waits until finished (requires authentication)

    • titleSlug: The URL slug/identifier of the problem (string, required)

    • lang: Programming language (string enum, required)

    • typedCode: Source code to run (string, required)

    • dataInput: Custom input to run (string, optional)

    • timeoutMs: Polling timeout in milliseconds (number, optional, default: 120000)

    • pollIntervalMs: Polling interval in milliseconds (number, optional, default: 1500)

  • submit_solution - Submits code for a specific problem and waits until finished (requires authentication)

    • titleSlug: The URL slug/identifier of the problem (string, required)

    • lang: Programming language (string enum, required)

    • typedCode: Source code to submit (string, required)

    • timeoutMs: Polling timeout in milliseconds (number, optional, default: 120000)

    • pollIntervalMs: Polling interval in milliseconds (number, optional, default: 1500)

Notes

  • search_notes - Searches for user notes on LeetCode China

    • keyword: Search term to filter notes (string, optional)

    • limit: Maximum number of notes to return (number, optional, default: 10)

    • skip: Number of notes to skip (number, optional, default: 0)

    • orderBy: Sort order for returned notes (enum: "ASCENDING", "DESCENDING", optional, default: "DESCENDING")

  • get_note - Retrieves user notes for a specific LeetCode problem

    • questionId: The question ID of the LeetCode problem (string, required)

    • limit: Maximum number of notes to return (number, optional, default: 10)

    • skip: Number of notes to skip (number, optional, default: 0)

  • create_note - Creates a new note for a specific LeetCode problem

    • questionId: The question ID of the LeetCode problem (string, required)

    • content: The content of the note, supports markdown format (string, required)

    • summary: An optional short summary or title for the note (string, optional)

  • update_note - Updates an existing note with new content or summary

    • noteId: The ID of the note to update (string, required)

    • content: The new content for the note, supports markdown format (string, required)

    • summary: An optional new short summary or title for the note (string, optional)

Solutions

  • list_problem_solutions - Retrieves a list of community solutions for a specific problem

    • questionSlug: The URL slug/identifier of the problem (string, required)

    • limit: Maximum number of solutions to return (number, optional, default: 10)

    • skip: Number of solutions to skip (number, optional)

    • userInput: Search term to filter solutions (string, optional)

    • tagSlugs: Array of tag identifiers to filter solutions (string[], optional, default: [])

    • orderBy: Sorting criteria for the returned solutions

      • Global: enum: "HOT", "MOST_RECENT", "MOST_VOTES", optional, default: "HOT"

      • CN: enum: "DEFAULT", "MOST_UPVOTE", "HOT", "NEWEST_TO_OLDEST", "OLDEST_TO_NEWEST", optional, default: "DEFAULT"

  • get_problem_solution - Retrieves the complete content of a specific solution

    • topicId: Unique topic ID of the solution (string, required, Global only)

    • slug: Unique slug/identifier of the solution (string, required, CN only)

Available Resources

Resource Name

Global

CN

Auth Required

Description

problem-categories

✅

✅

❌

A list of all problem classification categories

problem-tags

✅

✅

❌

A detailed collection of algorithmic and data structure tags

problem-langs

✅

✅

❌

A complete list of all supported programming languages

problem-detail

✅

✅

❌

Provides details about a specific problem

problem-solution

✅

✅

❌

Provides the complete content of a specific solution

Resource URIs

  • problem-categories - A list of all problem classification categories

    • URI: categories://problems/all

  • problem-tags - A detailed collection of algorithmic and data structure tags

    • URI: tags://problems/all

  • problem-langs - A complete list of all programming languages supported by LeetCode

    • URI: langs://problems/all

  • problem-detail - Provides details about a specific LeetCode problem

    • URI: problem://{titleSlug}

    • Parameters:

      • titleSlug: Problem identifier as it appears in the LeetCode URL

  • problem-solution - Provides the complete content of a specific solution

    • Global URI: solution://{topicId}

      • Parameters:

        • topicId: Unique topic ID of the solution

    • CN URI: solution://{slug}

      • Parameters:

        • slug: Unique slug/identifier of the solution

Authentication

User-specific data access requires LeetCode session authentication:

  1. Log in to LeetCode (Global or China site)

  2. Extract LEETCODE_SESSION cookie from browser developer tools

  3. Configure server with --session flag or LEETCODE_SESSION environment variable

Response Format

All tools return JSON-formatted responses with the following structure:

{
  "content": [
    {
      "type": "text",
      "text": "JSON_DATA_STRING"
    }
  ]
}

The JSON_DATA_STRING contains either the requested data or an error message for failed requests.

License

This project is licensed under the MIT License.

Available Tools

9 tools
get_daily_challengeA

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.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.7/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden, and it does disclose the important traits: read-only, no authentication required, and that it returns JSON details for the current date. It does not cover edge behavior such as what is returned on a day without a challenge or whether results are cached, which keeps it short of a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences, front-loaded with what it does and its safety profile, then routing guidance. No sentence is redundant or padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a parameterless, read-only retrieval tool with no output schema, the description supplies everything an agent needs: what it returns, its scope (today), its auth/safety profile, and how it relates to the two sibling retrieval tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, which is the baseline-4 case per the rubric. The description implicitly confirms this by framing the date as fixed ('current date') rather than something the caller supplies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Retrieves today's Daily Challenge problem') and immediately qualifies scope ('today's', 'current date'). It is clearly distinguishable from get_problem (needs a titleSlug) and search_problems (filter-based discovery).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly names both alternatives and the condition that selects each: get_problem when a titleSlug is known, search_problems when discovering by filters. The implicit 'use this when you want today's challenge with no known identifier' is unambiguous from the contrast.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_problemA

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
titleSlugYesProblem URL slug (e.g., 'two-sum', 'add-two-numbers')—the path segment after /problems/

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does disclose the safety profile ('read-only, no auth') plus the payload shape ('description, examples, constraints, and metadata as JSON'). It stops short of noting failure behavior for an invalid slug or any rate-limit/pagination concerns, so it is strong but not complete.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three compact sentences, each with a distinct job: what it returns, how it authenticates/behaves, and how it differs from siblings. Front-loaded with the core action and no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter read tool with a 100%-covered schema and no output schema, the description supplies the return payload contents, the auth/safety stance, and sibling routing. An agent has everything needed to select and call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the single titleSlug parameter is already fully documented with format examples in the schema. The description only restates 'by titleSlug' with no added syntax or edge-case guidance, so it earns the baseline 3 rather than more.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Starts with a specific verb+resource ('Retrieves a single LeetCode problem') and explicitly scopes it to lookup by titleSlug. It also names the sibling tools it must be distinguished from, so an agent can disambiguate without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit routing: 'Use search_problems to find problems by keyword/tag/difficulty; use get_daily_challenge for today's featured problem.' Both the condition and the alternative are named, leaving nothing to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_problem_solutionA

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
topicIdYesSolution topicId from list_problem_solutions response

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description fully covers behavioral traits: read-only, no authentication, and return format (JSON with text, author, metadata).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three concise sentences, front-loaded with purpose and safety, no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Complete for a simple retrieval tool with one parameter and no output schema; mentions return fields and prerequisite step. Could specify error cases, but not required.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, baseline 3. The description adds value by explaining the topicId's origin from list_problem_solutions, which is not in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Retrieves full content of a community solution article' with specific verb and resource. It is unambiguous and needs no sibling differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly instructs to first use list_problem_solutions to obtain topicId, providing clear prerequisite and sequential usage guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_recent_ac_submissionsA

Retrieves a user's recent accepted (AC) submissions (read-only, no auth). Available on both Global and CN. Use get_recent_submissions (Global only) to include failed attempts, or get_all_submissions (auth, current user) for full paginated history.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoMax AC submissions to return (default: 10)
usernameYesLeetCode username whose public recent AC submissions to fetch

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden and does well: it discloses read-only behavior, that no auth is required, and that it works on both Global and CN. It does not state return format or whether the limit truncates silently, which is the remaining gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, front-loaded with the core action and scope, then the disambiguation. Every sentence earns its place with zero redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple two-parameter list tool with no output schema, the description covers purpose, auth, region availability, and sibling routing. Only the shape of returned data is unaddressed, a minor omission given the tool's simplicity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and both parameters (username, limit with default) are fully documented in the schema. The description adds no syntax or format detail beyond what the schema already provides, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Retrieves a user's recent accepted (AC) submissions') and immediately bounds scope with read-only, no-auth, and dual-region availability. An agent can distinguish this from get_recent_submissions and get_all_submissions without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly names both alternatives with the condition that selects them: get_recent_submissions for failed attempts (Global only), get_all_submissions for full paginated history (auth, current user). This is textbook when-to-use routing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_recent_submissionsA

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoMax submissions to return (default: 10). Increase for more history within the recent window.
usernameYesLeetCode username whose public recent submissions to fetch

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does well: it declares read-only, no auth, acceptance-status coverage, and the Global-only limitation (not available on CN). It does not describe the return shape or the meaning of the 'recent window' boundary, so it falls short of fully explicit but is well above adequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences: capability + scope first, then routing to alternatives. No filler, nothing repeated from the schema, and the most decision-relevant constraint (Global only) is front-loaded with the rest.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter read tool with no output schema, the description covers safety, availability, and sibling routing adequately. It leaves the returned submission fields and the boundary of the 'recent window' unspecified, but nothing critical to correct invocation is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both parameters (username, limit) are already documented with defaults and intent in the schema. The description adds no syntax, range, or format detail beyond that, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Retrieves) and resource (a user's recent submission history) with explicit scope: LeetCode Global, read-only, no auth. It also clarifies it includes both accepted and failed submissions, which distinguishes it from the accepted-only sibling without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly names two alternatives and the condition that selects each: get_recent_ac_submissions for accepted-only, get_all_submissions for paginated full history with filters (auth, current user). This is textbook when-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_user_contest_rankingA

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
attendedNotrue = only contests the user attended (default); false = include all contests in history
usernameYesLeetCode username whose contest ranking to fetch

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full behavioral burden. It clearly discloses the operation is read-only and requires no auth, and it states the return shape (JSON with rating, ranking, per-contest performance). It omits potential failure modes or rate limits, but for a simple read-only lookup the key behavioral traits are covered.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, all informative and non-redundant. The core action and return value are front-loaded, and the sibling guidance appears at the end without diluting the primary message.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter read-only tool with no output schema, the description covers the essential contextual needs: what it returns, that it requires no auth, and when to choose it over the sibling. Nothing an agent needs to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with both username and attended already documented in the schema. The description adds no new parameter-level meaning, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description opens with a specific verb and resource: 'Retrieves a user's contest ranking and participation history.' It also distinguishes itself from get_user_profile by naming the exact difference (contest performance vs general stats), so an agent can select it unambiguously.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use the alternative ('Use get_user_profile for general stats and ranking') and when to use this tool ('use this specifically for contest performance data'). This is direct routing guidance with no inference required.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_user_profileA

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
usernameYesLeetCode username (case-sensitive). Public profile lookup; no authentication required.

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does well: it discloses read-only behavior, that no auth is required, and enumerates the returned fields (ranking, avatar, bio, submission stats, platform progress). It doesn't cover rate limits or failure behavior for unknown usernames, so not a full 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences, front-loaded with the purpose and return contents before the sibling routing guidance. Every sentence earns its place with no repetition of the schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Though there is no output schema, the description lists what is returned, and the auth/read-only posture is explicit despite missing annotations. The only thin area is edge-case behavior (invalid or nonexistent usernames), which is not addressed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and already states the username is case-sensitive and requires no auth. The description adds no syntax or format detail beyond the schema, so the baseline 3 applies for a single fully-documented parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Retrieves any user's public profile by username') and immediately scopes it as public/read-only. It also names the sibling it must not be confused with, so an agent can distinguish it from get_user_status without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives both sides of the routing decision: use this for looking up other users or public stats, and use get_user_status (requiring auth) for verifying the current session user. It even adds an exclusion ('not for looking up arbitrary users'), leaving nothing to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_problem_solutionsA

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
skipNoSolutions to skip for pagination (default: 0)
limitNoMax solutions per page (default: 10)
orderByNoSort order: 'HOT' (default), 'MOST_VOTES', or 'MOST_RECENT'HOT
tagSlugsNoFilter by language or algorithm tags, e.g. ['python', 'dynamic-programming']
userInputNoKeyword filter on solution title, content, or author (case-insensitive)
questionSlugYesProblem URL slug (e.g., 'two-sum')—same as in /problems/{slug}

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does well: it discloses read-only, no-auth, and that only metadata (topicId) is returned rather than article text. It stops short of describing pagination behavior despite skip/limit params, but the core behavioral profile is covered.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences, front-loaded with the scope and return-shape caveat before the alternative and the exclusion. No filler whatsoever.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description compensates by explaining exactly what comes back (metadata with topicId, not content) and the follow-up call. Everything an agent needs to invoke it correctly is present.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all six parameters are self-documented with defaults and examples. The description adds no syntax or format detail beyond the schema, which is the baseline 3 case when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Lists community solution articles for a problem') and immediately bounds the scope ('Returns metadata only (topicId)—not full content'). An agent can distinguish it from get_problem_solution without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly names the alternative (get_problem_solution) with the returned topicId, and gives a clear when-not rule: 'Do not call this when you already have a topicId and need the solution text.' Routing is unambiguous.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_problemsA

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
tagsNoTopic tags to filter by, e.g. ['array', 'dynamic-programming']. Omit for no tag filter.
limitNoMax results per page (default: 10)
offsetNoResults to skip for pagination (default: 0)
categoryNoProblem set category (e.g., 'algorithms', 'database'). Default: 'all-code-essentials'.all-code-essentials
difficultyNoDifficulty filter. Omit for all levels.
searchKeywordsNoKeyword search in problem titles and descriptions

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden and does well: it discloses read-only semantics, that no auth is required, that pagination is via limit/offset, and that results come back as JSON. It stops short of stating rate limits, a maximum page size, or total-result behavior, which would matter for a browse tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, zero filler. Capabilities come first, then pagination/return, then the routing guidance, so the most decision-relevant information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a six-parameter, no-output-schema, no-annotation tool, the description covers purpose, safety, auth, pagination, and return type, which is enough to invoke correctly. It could say a bit more about the shape of each result item, but the essential contract is present.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so every parameter is already documented in the schema, and the description adds little beyond echoing that limit/offset drive pagination. Baseline 3 is appropriate when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Searches LeetCode problems') plus the exact filter dimensions it operates on. It also explicitly distinguishes itself from the sibling get_problem, so an agent can route between the two without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit when-to-use rule: 'Use get_problem when you already know the titleSlug; use this to browse or discover problems.' This names the alternative sibling and the condition that selects one over the other, leaving nothing to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 9 tool updatesv1.4.0
    • First observedget_daily_challenge
    • First observedget_problem
    • First observedget_problem_solution
    • First observedget_recent_ac_submissions
    • First observedget_recent_submissions
    • First observedget_user_contest_ranking
    • First observedget_user_profile
    • First observedlist_problem_solutions
    • First observedsearch_problems
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.4/5.0

Scored across 9 tools

Disambiguation4/5

Most tools have clearly distinct purposes (e.g., get_problem vs search_problems vs get_daily_challenge). Slight overlap exists between get_recent_submissions and get_recent_ac_submissions, and between get_user_profile and get_user_contest_ranking, but descriptions help differentiate them.

Naming Consistency5/5

All tools follow a consistent snake_case verb_noun pattern (get_daily_challenge, get_problem, search_problems, etc.). Minor variation between get_ and list_ verbs is natural and still predictable.

Tool Count5/5

9 tools is well-scoped for a read-only LeetCode data access server. Each tool covers a distinct aspect (problems, users, submissions, solutions) without redundancy.

Completeness3/5

The set covers core read-only operations, but several tools referenced in descriptions are absent (get_user_status, get_all_submissions), leaving gaps for authenticated full submission history and session verification. These missing operations could cause agent failures when those capabilities are expected.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers