Which integrations are available for this server?

Provides tools for fetching, running, and submitting LeetCode problems and solutions.

How do I use LeetCode MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@LeetCode MCP Server fetch the daily LeetCode challenge" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

LeetCode MCP Server

by AHM215

Overview Schema Related Servers Score Discussions

Python

Remote

LeetCode MCP Server

Docker Pulls Build Status License: MIT

An MCP-compatible server that exposes a set of tools to interact with the LeetCode API. This allows you to fetch problems, generate code templates, run, and submit solutions programmatically.

Overview

This project provides a simple and effective way to interface with LeetCode's services. It's built using Python and the mcp framework, exposing functionalities as tools that can be easily integrated into other applications or used for automating LeetCode tasks.

Related MCP server: LeetCode MCP Server

Features

Fetch Problem Details: Get the full description, examples, and constraints for any LeetCode problem.
Code Template Generation: Generate starter code for any problem in your preferred language.
Run Code: Test your solution against the example test cases.
Submit Code: Submit your solution for evaluation against the full test suite.
Daily Challenge: Fetch the current daily LeetCode challenge.
Search Problems: Search for problems with various filters like tags, difficulty, and keywords.

Getting Started

Prerequisites

Python 3.12+
Docker (for containerized deployment)
Git

Configuration

To interact with the LeetCode API, you need to provide your LEETCODE_SESSION and LEETCODE_CSRFTOKEN cookies.

Log in to your LeetCode account in your web browser.
Open the developer tools (usually by pressing F12 or Ctrl+Shift+I).
Go to the Application (or Storage) tab.
Find the Cookies section and select https://leetcode.com.
Locate the LEETCODE_SESSION and csrftoken cookies and copy their values.

Create a .env file in the root of the project and add your credentials:

# .env
LEETCODE_SESSION=your_leetcode_session_cookie
LEETCODE_CSRFTOKEN=your_leetcode_csrftoken

Local Installation

Clone the repository:

git clone https://github.com/AHM215/leetcode-mcp.git
cd leetcode-mcp

Install dependencies:
```
pip install uv
uv pip install -e .
```
Run the server:
```
uv run python run_server.py
```
The server will start, and you can interact with it using an MCP client.

Docker Usage

Pull from Docker Hub

You can pull the pre-built Docker image from Docker Hub.

docker pull ahm215/leetcode-mcp-server:latest

Run with Docker

To run the server using Docker, you need to pass your LeetCode credentials as environment variables.

docker run -d \
  -p 8000:8000 \
  --name leetcode-mcp-server \
  -e LEETCODE_SESSION="your_leetcode_session_cookie" \
  -e LEETCODE_CSRFTOKEN="your_leetcode_csrftoken" \
  ahm215/leetcode-mcp-server:latest

Build from Source

You can also build the Docker image from the source code.

Clone the repository (if you haven't already).
Build the image:
```
docker build -t leetcode-mcp-server .
```
Run the container as shown in the "Run with Docker" section, using leetcode-mcp-server as the image name.

Claude Desktop Usage

If you want to run this server as a tool in a Claude Desktop environment, you can use the following JSON configuration. This defines a tool that runs the Docker container and passes the necessary credentials.

Note: You must replace the placeholder values for --leetcode-session and --csrftoken with your actual LeetCode cookies.

"docker-leetcode-mcp-server": {
  "type": "stdio",
  "command": "docker",
  "args": [
    "run",
    "-i",
    "--rm",
    "ahm215/leetcode-mcp-server:v1.0.0",
    "--leetcode-session",
    "your_leetcode_session_cookie",
    "--csrftoken",
    "your_leetcode_csrftoken"
  ]
}

Available Tools (API)

The server exposes the following tools:

`fetch_problem_plain_text`

Fetches the plain text content of a LeetCode problem given its URL.

Parameters:
- link (str): The full URL of the LeetCode problem.
Returns: (str) The plain text description of the problem.

`generate_template`

Generates a language-specific code template for a given LeetCode problem.

Parameters:
- problem_slug (str): The slug of the problem from its URL (e.g., "two-sum").
- code_lang (str): The language slug (e.g., "python3", "java", "cpp").
Returns: (str) The code template.

`run_code`

Executes code against the example test cases for a LeetCode problem.

Parameters:
- problem_slug (str): The slug of the problem.
- code_lang (str): The language slug.
- code (str): The code to be executed.
Returns: (dict) The results of the execution.

`submit_code`

Submits code for a LeetCode problem for evaluation against the full test suite.

Parameters:
- problem_slug (str): The slug of the problem.
- code_lang (str): The language slug.
- code (str): The code to be submitted.
Returns: (dict) The submission result.

`get_daily_challenge`

Retrieves today's LeetCode Daily Challenge problem.

Parameters: None
Returns: (dict) Details of the daily challenge problem.

`get_problem`

Retrieves details about a specific LeetCode problem.

Parameters:
- titleSlug (str): The slug of the problem.
Returns: (dict) Detailed information about the problem.

`search_problems`

Searches for LeetCode problems based on various filters.

Parameters:
- category (str, optional): The category to search in. Defaults to "all-code-essentials".
- tags (List[str], optional): A list of tags to filter by.
- difficulty (str, optional): The difficulty level ("EASY", "MEDIUM", "HARD").
- searchKeywords (str, optional): Keywords to search for.
- limit (int, optional): The number of results to return. Defaults to 10.
- offset (int, optional): The offset for pagination. Defaults to 0.
Returns: (dict) A list of problems matching the criteria.

Contributing

Contributions are welcome! Please feel free to submit a pull request or open an issue if you have any suggestions or find any bugs.

Fork the repository.
Create your feature branch (git checkout -b feature/AmazingFeature).
Commit your changes (git commit -m 'Add some AmazingFeature').
Push to the branch (git push origin feature/AmazingFeature).
Open a pull request.

License

This project is licensed under the MIT License. See the LICENSE file for details.

Available Tools

7 tools

fetch_problem_plain_textC

Fetches the plain text content of a LeetCode problem given its URL.

ParametersJSON Schema

Name	Required	Description	Default
`link`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.9/5.0

Behavior2/5

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

No annotations exist, so the description carries full burden. It does not disclose any behavioral traits such as idempotency, rate limits, or error conditions. Only a basic fetch action is implied.

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

Conciseness4/5

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

The description is concise (13 words) and uses a single sentence. It efficiently conveys the core action, though it could be more informative.

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

Completeness3/5

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

Given one parameter and presence of an output schema, the description is minimally sufficient. However, it omits details about input format, error handling, and what 'plain text' means relative to the problem, which could affect agent understanding.

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?

The schema has 0% description coverage, leaving 'link' undefined. The description partially compensates by stating 'given its URL', but does not specify format (e.g., full URL vs slug) or required prefix.

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

Purpose4/5

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

The description clearly states the verb 'Fetches' and the resource 'plain text content of a LeetCode problem', and specifies the input as a URL. However, it does not differentiate from sibling tool 'get_problem', which likely also fetches problem data.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus siblings like 'get_problem' or 'search_problems'. The description only states what it does, not when it is appropriate.

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

generate_templateB

Generates a language-specific code template for a given LeetCode problem slug.

ParametersJSON Schema

Name	Required	Description	Default
`code_lang`	Yes
`problem_slug`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3/5.0

Behavior2/5

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

No annotations are provided, so the description carries full responsibility for behavioral disclosure. The description only states what the tool does, but fails to reveal any behavioral traits such as whether it is a read-only operation, any side effects, authentication requirements, rate limits, or output format. For a template generation tool, one might assume it is safe, but the description does not confirm this.

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?

The description is a single sentence of 12 words, extremely concise and structured to present the core function immediately. There is no extraneous information, and the sentence is front-loaded with the verb 'Generates' followed by the resource type. Every word contributes to understanding the tool's purpose.

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

Completeness3/5

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

Given that there is an output schema (though not provided), the description does not need to detail return values. However, the tool has two required parameters with no descriptions either in the schema or the description, and the description does not clarify what the generated template looks like. For example, does it include function signatures, imports, or comments? The description also does not relate the tool to the sibling tools (e.g., that it should be used before 'run_code'). It is minimally complete but leaves the user with unanswered questions.

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

Parameters1/5

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

The input schema has 0% description coverage, meaning no parameter descriptions exist in the schema. The tool description does not add any semantic meaning to the parameters beyond mentioning them implicitly. It does not explain what constitutes a valid 'problem_slug' (e.g., format like 'two-sum') or 'code_lang' (e.g., 'python', 'java'). There are no examples or constraints, leaving the agent to guess the expected values.

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 the tool 'generates a language-specific code template for a given LeetCode problem slug.' The verb 'generates' and the specific resource 'code template' combined with the inputs 'problem_slug' and 'code_lang' make the purpose unmistakable. It also distinguishes itself from siblings like 'run_code' or 'submit_code' which are execution actions, and 'fetch_problem_plain_text' which retrieves plain text, not a template.

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

Usage Guidelines2/5

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

The description provides no explicit guidance on when to use this tool versus its alternatives. It does not mention prerequisites, context, or when not to use it. For example, it could have indicated that this is the first step before writing and submitting code, but it does not. With siblings that perform different tasks, the lack of usage direction is a notable gap.

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

get_daily_challengeA

Retrieves today's LeetCode Daily Challenge problem with complete details, including problem description, constraints, and examples.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations, the description carries full burden. It discloses the tool is a read operation ('Retrieves') and lists the returned content (description, constraints, examples). It does not mention potential side effects or rate limits, but the behavior is simple and adequately described.

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?

The description is a single, clear sentence with no extraneous words. It is front-loaded with the purpose and provides essential detail about the return content.

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?

Given no output schema, the description explains return values ('problem description, constraints, and examples') which is sufficient for a simple retrieval tool. However, it lacks specificity about the exact structure or metadata elements.

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 has zero parameters and schema coverage is 100%. According to guidelines, 0 params warrants a baseline of 4. The description adds no parameter info because none exist.

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 the verb 'Retrieves', the resource 'today's LeetCode Daily Challenge problem', and specifies the scope ('today's') and content ('complete details, including problem description, constraints, and examples'). It effectively distinguishes from siblings like get_problem (for specific problems) and search_problems.

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

Usage Guidelines3/5

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

The description implies usage for retrieving today's challenge but provides no explicit guidance on when to use this tool versus alternatives (e.g., get_problem, search_problems). No when-not-to-use or exclusions are given.

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

get_problemC

Retrieves details about a specific LeetCode problem, including its description, examples, constraints, and related information.

ParametersJSON Schema

Name	Required	Description	Default
`titleSlug`	Yes

TDQS

C2.8/5.0

Behavior3/5

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

No annotations are present, so the description carries the full burden. It does not explicitly state that the operation is read-only or idempotent, though the action 'retrieves' implies no side effects. The description is adequate but lacks explicit behavioral disclosure.

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

Conciseness3/5

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

The description is a single sentence that is reasonably concise, but it could be structured more effectively (e.g., listing key components) and still fits within acceptable length.

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

Completeness2/5

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

With only one parameter and no output schema, the description should compensate by detailing the parameter and expected return value. It mentions 'related information' vaguely and does not specify what exactly is returned, leaving the agent uncertain.

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

Parameters2/5

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

Schema description coverage is 0%, and the description does not explain the `titleSlug` parameter—what it represents, expected format, or how to obtain it. This is a significant gap given the single parameter.

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

Purpose4/5

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

The description clearly states it retrieves details about a specific LeetCode problem including description, examples, constraints, and related information. However, it does not differentiate from the sibling tool `fetch_problem_plain_text`, which also retrieves a problem.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool vs siblings like `fetch_problem_plain_text` or `search_problems`. It does not specify prerequisites or context for usage.

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

run_codeC

Executes code against the example test cases for a LeetCode problem and returns the results.

ParametersJSON Schema

Name	Required	Description	Default
`code`	Yes
`code_lang`	Yes
`problem_slug`	Yes

TDQS

C2.8/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. It states 'returns the results' but does not disclose side effects (e.g., attempt tracking, rate limits, execution timeouts, error behavior). For a code execution tool, critical behavioral aspects are missing. Score 2.

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

Conciseness4/5

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

Single sentence is concise, but could be more structured (e.g., listing parameters). However, it's front-loaded with the action. Score 4 for being appropriately brief.

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

Completeness2/5

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

Given the tool's complexity (code execution, 3 params, no output schema, no annotations), the description is insufficient. It omits return format, error handling, language support, and execution context. Score 2 for being incomplete.

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

Parameters1/5

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

Schema description coverage is 0%. The description does not explain what 'problem_slug', 'code_lang', or 'code' mean (e.g., valid code_lang values, code format). It adds no meaning beyond parameter names. Score 1 as it fails to compensate for missing schema descriptions.

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

Purpose4/5

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

Clearly states 'Executes code against the example test cases' – verb (executes) and resource (code against example test cases) are specific. Differentiates from siblings like submit_code (which likely uses all test cases), though not explicitly. Score 4 because it's clear but 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 Guidelines3/5

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

Implied usage: use this to test code against example cases before submission. But no explicit when-to-use, when-not-to-use, or alternative tools (e.g., 'Use this for quick testing; use submit_code for final submission'). Score 3 for implied but no explicit guidance.

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

search_problemsA

Searches for LeetCode problems based on multiple filter criteria including categories, tags, difficulty levels, and keywords, with pagination support.

ParametersJSON Schema

Name	Required	Default
`tags`	No
`limit`	No
`offset`	No
`category`	No	all-code-essentials
`difficulty`	No
`searchKeywords`	No

TDQS

A3.7/5.0

Behavior3/5

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

With no annotations, the description carries the full burden. It mentions 'pagination support' but does not explain pagination mechanics, result ordering, or authentication requirements. It is adequate but lacks depth.

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?

The description is a single, well-structured sentence of 20 words. It begins with the verb and key action, conveying essential information without redundancy.

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

Completeness3/5

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

Given 6 parameters, no output schema, and no annotations, the description covers the filtering and pagination but omits the return format, result ordering, and authentication. It is incomplete for a search tool.

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 description coverage is 0%, so the description compensates by naming filter categories (categories, tags, difficulty, keywords) that map to parameters. It adds meaning beyond the schema, though it could enumerate allowed values (e.g., difficulty levels).

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 the tool's action ('Searches'), the resource ('LeetCode problems'), and the filtering criteria (categories, tags, difficulty, keywords) with pagination. It differentiates from siblings like get_problem which targets a single problem.

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

Usage Guidelines2/5

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

The description lacks any guidance on when to use this tool versus alternatives, such as recommending get_problem for specific problem lookups or generate_template for code generation. No exclusions or context are provided.

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

submit_codeC

Submits the code for a LeetCode problem for evaluation against the full test suite.

ParametersJSON Schema

Name	Required	Description	Default
`code`	Yes
`code_lang`	Yes
`problem_slug`	Yes

TDQS

C2.7/5.0

Behavior2/5

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

No annotations provided, and description does not disclose side effects (e.g., submission quota, timeouts) or return format. Only states evaluation purpose.

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?

Single sentence with clear verb and target. No unnecessary words; front-loaded purpose.

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

Completeness2/5

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

No output schema; missing parameter guidance and behavioral context. Barely adequate for 3-param tool.

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

Parameters1/5

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

Schema coverage is 0%; description adds no parameter details. Required params (problem_slug, code_lang, code) lack format or constraints, leaving agent to guess.

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

Purpose4/5

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

The description clearly states the action (submits code) and the purpose (evaluation against full test suite), distinguishing it from run_code which likely runs sample tests. However, it could be more explicit about the difference.

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

Usage Guidelines2/5

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

No guidance on when to use this tool vs siblings like run_code. Does not mention prerequisites or alternative scenarios.

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. Dates show when Glama detected each change.

7 tool updatesv0.1.0Jul 30, 2026
- First observedfetch_problem_plain_text
- First observedgenerate_template
- First observedget_daily_challenge
- First observedget_problem
- First observedrun_code
- First observedsearch_problems
- First observedsubmit_code

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.5/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: fetching problem text, generating templates, running/submitting code, retrieving daily challenge, getting full problem details, and searching. No two tools overlap in functionality.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with underscores (e.g., fetch_problem_plain_text, run_code, submit_code). No mixing of styles.

Tool Count5/5

Seven tools is well-scoped for a LeetCode problem-solving assistant, covering essential operations from retrieval to submission without unnecessary extras.

Completeness4/5

The tool set covers core workflows: fetch, template, run, submit, search, and daily challenge. Minor gaps like user account management or submission history are absent but not critical for the primary use case.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

neverinfamous-memory-journal-mcp
ai.smithery
A MCP server built for developers enabling Git based project management with project and personal…
Version Control Developer Tools Project Management
320
gread A
io.github.NitroRCr
An MCP server that gives your AI access to the source code and docs of all public github repos
Version Control Code Analysis Documentation Access
5361
server B
io.cycloid.mcp
An MCP server that let you interact with Cycloid.io Internal Development Portal and Platform
Developer Tools CI/CD & DevOps Cloud Platforms
62
mcp A
ai.llmse
Public MCP server for the LLM Search Engine
Search RAG Systems Developer Tools
102

Related MCP Servers

mcp-server-leetcode
Education & Learning Tools Code Execution Developer Tools
doggybee
A
license
C
quality
F
maintenance
A Model Context Protocol (MCP) server for LeetCode that enables AI assistants to access LeetCode problems, user information, and contest data.
Updated a year ago (2025-04-02 14:27 UTC)
7
24
43
MIT
LeetCode MCP Server
Coding Agents Developer Tools
jinzcdev
A
license
A
quality
A
maintenance
A Model Context Protocol server that provides integration with LeetCode APIs, enabling automated interaction with programming problems, contests, solutions, and user data across both leetcode.com and leetcode.cn platforms.
Updated 2 months ago (2026-07-12 12:05 UTC)
9
239
141
MIT
leetcode-helper
Education & Learning Tools Developer Tools
Navoren
F
license
Not graded
quality
C
maintenance
An MCP server that provides structured, AI-powered guidance for LeetCode problems, including approach analysis, hints, complexity breakdowns, and optimization directions without spoiling solutions.
Updated 2 months ago (2026-06-24 11:11 UTC)
4
1
-
LeetCode MCP
Education & Learning Tools Developer Tools
akshaya-cp
F
license
Not graded
quality
C
maintenance
A tutorial and working MCP server that connects to your LeetCode profile, enabling AI assistants to check solved problems and recommend new ones by topic and difficulty.
Updated 2 months ago (2026-07-04 10:03 UTC)
1
-

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/AHM215/LeetCode-MCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server