The mcp-server-leetcode is a Model Context Protocol (MCP) server that provides access to LeetCode data, enabling AI assistants to interact with LeetCode problems, user profiles, and contest information.
With this server you can:
Access LeetCode problems: Retrieve daily challenges, search for problems by tags/difficulty, and get problem details by slug
Fetch user data: Access user profiles, submission history, and contest rankings
Contest information: Retrieve details about specific contests by slug
Integration: Supports integration with AI assistants like Claude for Desktop
Programmable API: Can be used as a library for custom applications
Provides access to LeetCode problems, daily challenges, user profiles, submission history, contest data, and rankings through the LeetCode API.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-server-leetcode get today's daily 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.
A Model Context Protocol (MCP) server for LeetCode that enables AI assistants to access LeetCode problems, user information, and contest data.
🚀 Fast access to LeetCode API
🔍 Search problems, retrieve daily challenges, and check user profiles
🏆 Query contest data and rankings
🧩 Full support for MCP tools and resources
📦 Provides both CLI and programmable API
Related MCP server: LeetCode MCP Server
To install mcp-server-leetcode for Claude Desktop automatically via Smithery:
npx -y @smithery/cli install @doggybee/mcp-server-leetcode --client claudenpm install -g @mcpfun/mcp-server-leetcodeOnce installed, you can run it directly from the command line:
mcp-server-leetcodenpm install @mcpfun/mcp-server-leetcodeAdd the following to your Claude for Desktop claude_desktop_config.json file:
{
"mcpServers": {
"leetcode": {
"command": "mcp-server-leetcode"
}
}
}For local development:
{
"mcpServers": {
"leetcode": {
"command": "node",
"args": ["/path/to/dist/index.js"]
}
}
}import { LeetCodeService } from '@mcpfun/mcp-server-leetcode';
// Initialize the service
const leetcodeService = new LeetCodeService();
// Get daily challenge
const dailyChallenge = await leetcodeService.getDailyChallenge();
// Search problems
const problems = await leetcodeService.searchProblems({
difficulty: 'MEDIUM',
tags: 'array+dynamic-programming'
});Tool Name | Description | Parameters |
| Get the daily challenge | None |
| Get details for a specific problem |
|
| Search for problems based on criteria |
|
Tool Name | Description | Parameters |
| Get user information |
|
| Get user submission history |
|
| Get user contest rankings |
|
Tool Name | Description | Parameters |
| Get contest details |
|
leetcode://daily-challenge: Daily challenge
leetcode://problem/{titleSlug}: Problem details
leetcode://problems{?tags,difficulty,limit,skip}: Problem list
leetcode://user/{username}/profile: User profile
leetcode://user/{username}/submissions{?limit}: User submissions
leetcode://user/{username}/contest-ranking: User contest ranking
Clone the repository and install dependencies:
git clone https://github.com/doggybee/mcp-server-leetcode.git
cd mcp-server-leetcode
npm installRun in development mode:
npm run devBuild the project:
npm run buildMIT
Model Context Protocol - MCP specifications and documentation
Claude for Desktop - AI assistant with MCP support
This project was inspired by alfa-leetcode-api
| Name | Required | Description | Default |
|---|---|---|---|
| contestSlug | Yes | The URL slug of the contest |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| titleSlug | Yes | The URL slug of the problem (e.g., 'two-sum') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| username | Yes | LeetCode username |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| username | Yes | LeetCode username |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| username | Yes | LeetCode username | |
| limit | No | Maximum number of submissions to return |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | Tags to filter by, separated by '+' (e.g., 'array+dynamic-programming') | |
| difficulty | No | Difficulty level | |
| limit | No | Maximum number of problems to return | |
| skip | No | Number of problems to skip |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose targeting different LeetCode resources: contests, daily challenges, problems, user rankings, profiles, submissions, and problem search. There is no overlap in functionality, making tool selection straightforward for an agent.
All tool names follow a consistent verb_noun pattern using kebab-case (e.g., get-contest-details, search-problems). The naming is uniform throughout with no deviations in style or convention.
With 7 tools, the server is well-scoped for a LeetCode integration, covering key areas like problem access, user data, and contests. Each tool serves a specific, necessary function without bloat.
The tool set provides comprehensive read-only coverage for LeetCode data, including problems, user profiles, contests, and submissions. A minor gap exists in write operations (e.g., submitting solutions or managing account settings), but core retrieval needs are fully met.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
MCP server for LeadDelta — manage LinkedIn connections and CRM data via AI assistants.
A Model Context Protocol server for Wix AI tools
MCP server for building and testing AI agents with multi-model experimentation and insights.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/doggybee/mcp-server-leetcode'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
