How do I use learn-mcp?

1. Click on "Deploy 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., "@learn-mcp generate me a medium graph problem with a story" 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.

learn-mcp

by abp2204

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

learn-mcp

An MCP server for agent-guided DSA practice. Connect it to an IDE agent (Claude Code, Cursor, etc.) and instead of static LeetCode problems, the agent generates immersive, LeetCode-style problems on demand and tutors you through them — escalating hints, concept explanations, and multi-step think-throughs.

The server provides structure and memory (problems, sessions, hint escalation, progress); the connected agent provides the creativity and teaching. No LLM runs inside the server.

Install

Install once from GitHub — it builds itself on install and exposes a learn-mcp command:

npm install -g github:abp2204/learn-mcp

Then register it with any MCP-capable agent. Because it's a global command, the config is the same in every folder — and so is your progress (one store in your home dir).

Claude Code:

claude mcp add learn-mcp -- learn-mcp

Cursor / Claude Desktop / any client (mcpServers config):

{
  "mcpServers": {
    "learn-mcp": { "command": "learn-mcp" }
  }
}

Prefer not to install globally? Use npx instead — same effect, nothing installed:

{
  "mcpServers": {
    "learn-mcp": { "command": "npx", "args": ["-y", "github:abp2204/learn-mcp"] }
  }
}

Now open any project in your agent and say "generate me a medium graph problem" — it works regardless of which folder you're in.

From source (development)

git clone https://github.com/abp2204/learn-mcp && cd learn-mcp
npm install      # builds via the prepare script
npm run dev      # run from TS source (stdio)
npm run inspect  # explore the tools in the MCP Inspector

Related MCP server: LeetCode MCP Server

How a session goes

You ask the agent for, say, a medium graph problem with a story.
Agent authors it and calls generate_problem → it's stored with a stable id.
start_session drops you into the problem (answers hidden).
Stuck? get_hint escalates 1 → 4 (nudge → near-solution); the server tracks the level so hints don't over-reveal. explain_concept teaches an underlying idea. next_step advances multi-step problems.
submit_solution records your attempt; a pass marks it solved.
progress shows what you've solved and which topics are weak.

Tools

Tool	Purpose
`generate_problem`	Store an agent-authored, LeetCode-style problem
`start_session`	Begin a session; returns the solver-facing problem + `sessionId`
`get_hint`	Advance the escalating hint level (server-tracked)
`explain_concept`	Record/echo a taught concept
`submit_solution`	Record an attempt; `pass` solves the session
`next_step`	Advance a multi-step problem
`progress`	Single-user stats, solved-by-difficulty, weak topics

Plus an author_problem MCP prompt: a rubric the agent can pull in to write well-calibrated, immersive problems.

Storage

One global SQLite file in your home dir — ~/.learn-mcp/learn.sqlite (respects XDG_DATA_HOME; override with the LEARN_MCP_DB env var). This is why your problems and progress are shared across every folder and agent, and survive restarts. Uses Node's built-in node:sqlite, so there's no native build step. The server prints the active store path to stderr on startup.

Status

v1. Solutions are agent-judged (the agent evaluates your code and reports pass/fail). A sandboxed code executor with generated test cases is the planned next step. Domain is DSA; DSP is a parked future idea.

Development

See CLAUDE.md for architecture and conventions. Run the end-to-end test with:

node scripts/smoke.mjs

Requires Node 22.5+ (uses built-in node:sqlite).

Available Tools

7 tools

explain_conceptExplain conceptB

Record that a concept was taught during a session (keeps the flow's timeline honest) and echo the concept back. YOU write the explanation. Optionally tie it to a session for progress tracking.

ParametersJSON Schema

Name	Required	Description	Default
`concept`	Yes
`sessionId`	No

TDQS

B3.4/5.0

Behavior2/5

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

No annotations provided, so description must fully disclose behavior. It states recording (a write operation) but lacks details on side effects, authentication needs, or response format. Minimal disclosure.

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?

Two concise sentences that front-load the main action. No wasted words; every part contributes to understanding.

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 recording tool with no output schema and two params, the description covers purpose and parameters adequately. However, missing explicit mention of what the tool returns (the echo) leaves slight gap.

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?

With 0% schema description coverage, the description adds meaning: 'concept' is the taught item, 'sessionId' ties to progress tracking. This is basic but sufficient; could specify format or constraints.

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?

Description clearly states the tool records a taught concept and echoes it back, distinguishing it from sibling tools like generate_problem or get_hint. However, 'echo' is slightly ambiguous, and the purpose could be more precise.

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 mentions optional session tying for progress tracking, implying when to use for logging concepts. But no explicit guidance on when not to use or comparison to alternatives, limiting contextual advice.

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

generate_problemGenerate problemA

Store an agent-authored, LeetCode-style DSA problem and return its id/slug. YOU (the agent) write the creative, immersive content; this tool persists it with structure so it can be practiced in a session. For multi-step problems, provide steps. Provide a referenceApproach (hidden from the solver) to ground hints and judging.

ParametersJSON Schema

Name	Required	Description
`steps`	No	Only for multi-step problems
`theme`	No
`title`	Yes
`prompt`	Yes	Immersive problem statement (markdown)
`topics`	Yes	e.g. arrays, dp, graphs
`examples`	Yes
`difficulty`	Yes
`constraints`	No
`starterCode`	No	Keyed by language, e.g. { "typescript": "function ..." }
`referenceApproach`	No	Hidden from solver; grounds hints/reveals/judging

TDQS

A4/5.0

Behavior3/5

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

With no annotations provided, the description carries the burden. It mentions the tool returns an id/slug, and that 'referenceApproach' is hidden from the solver. However, it doesn't disclose potential side effects like overwriting existing problems or require permissions. It adds some value but lacks full transparency for a write operation.

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 two sentences with zero waste. It front-loads the purpose and return, then provides critical guidance. Every sentence earns its place.

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 the tool's complexity (10 parameters, nested objects, no output schema), the description covers the essential purpose, usage guidance, and key optional features. It lacks explicit mention of return value structure, which would be helpful but not critical. Overall complete enough for an agent to understand when and how to use it.

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 50%, so baseline is 3. The description adds meaning for 'steps' and 'referenceApproach' but doesn't elaborate on other parameters like 'title', 'difficulty', or 'examples'. The schema already covers some, but the description could provide more context for required parameters.

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 'Store' and the resource 'agent-authored, LeetCode-style DSA problem', and specifies the return value 'id/slug'. It distinguishes from sibling tools like 'explain_concept' and 'submit_solution' by focusing on problem creation.

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

Usage Guidelines4/5

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

The description explicitly tells when to provide 'steps' (for multi-step problems) and to always provide 'referenceApproach'. It implicitly guides usage by stating the tool persists content for practice sessions. While it doesn't explicitly say when not to use it, the context makes it clear it's for creation, not solving.

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

get_hintGet hintA

Advance the hint escalation for a session. Returns the level and guidance on HOW deep a hint to give at this level — YOU write the actual hint, grounded in the problem's referenceApproach. Levels run 1 (nudge) to 4 (near-solution).

ParametersJSON Schema

Name	Required	Description	Default
`sessionId`	Yes

TDQS

A3.8/5.0

Behavior3/5

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

No annotations exist, so the description must disclose behavior. It mentions advancing (mutation), returns level and guidance, and defines levels. But it does not cover side effects, auth needs, rate limits, or idempotency.

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?

Two sentences, front-loaded with action, no wasted words. Every part adds value.

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?

No output schema, so description should outline return structure; it says 'returns the level and guidance' but not types or possible values. Lacks error handling or prerequisites for a tutoring context.

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?

With only one parameter (sessionId) and 0% schema coverage, the description does not add meaning beyond the parameter name. It does not explain how to obtain the sessionId or its format.

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 advances hint escalation for a session, returns level and guidance, and distinguishes from siblings by focusing on hints. The verb 'advance' and resource 'hint escalation' are specific.

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

Usage Guidelines4/5

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

The description implies when to use (when a student needs a hint) and sets expectations by noting 'YOU write the actual hint'. However, it does not explicitly state when not to use or contrast with siblings.

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

next_stepNext stepB

Advance a multi-step problem to its next stage and return that step's prompt (its referenceApproach stays hidden). Errors if the problem is single-step or already at the last step.

ParametersJSON Schema

Name	Required	Description	Default
`sessionId`	Yes

TDQS

B3.4/5.0

Behavior3/5

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

With no annotations, description carries full burden. It mentions that referenceApproach stays hidden and that the tool advances state, and lists error cases. Lacks details on side effects or idempotency.

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 packed with purpose, return value, and error conditions. Efficient but could benefit from slight restructuring for readability.

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?

For a simple tool with one parameter and no output schema, description covers core behavior and constraints. However, lack of parameter explanation and sibling differentiation reduces completeness.

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?

Single parameter sessionId has no description in schema (0% coverage). Description does not explain its purpose or format, missing a key chance to add value.

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?

Description clearly states verb 'advance' and resource 'multi-step problem', and notes return value. However, it does not differentiate from sibling tools like 'progress' or 'get_hint'.

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

Usage Guidelines4/5

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

Description specifies error conditions (single-step or at last step), providing context for when not to use. Does not explicitly compare to alternatives.

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

progressProgressA

Single-user practice stats across all sessions: solved counts by difficulty, and per-topic attempted/solved (use to surface weak areas).

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.3/5.0

Behavior3/5

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

No annotations provided, so the description must carry the burden. It indicates the tool is read-only and aggregates data across sessions. However, it omits details like whether data resets, caching behavior, or authentication requirements.

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 that front-loads the key information: 'Single-user practice stats across all sessions'. Every phrase adds value without 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?

Given zero parameters and no output schema, the description sufficiently explains the output (difficulty counts, topic stats). It could mention the return format (e.g., JSON structure) but is adequate for a simple query tool.

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

Parameters5/5

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

The tool has no parameters (0 inputs), so the description instead explains what the output contains: solved counts by difficulty and per-topic statistics. This adds meaning beyond the empty 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 it returns practice stats for a single user, including solved counts by difficulty and per-topic attempted/solved. This is distinct from sibling tools like generate_problem or submit_solution.

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

Usage Guidelines4/5

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

The description explicitly says 'use to surface weak areas', providing a clear use case. While it doesn't exclude other scenarios, the purpose is well-defined enough for an agent to decide when to invoke it.

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

start_sessionStart sessionB

Begin a practice session for a stored problem. Returns the solver-facing problem (answers hidden) and a sessionId to use for hints, submissions, and steps.

ParametersJSON Schema

Name	Required	Description	Default
`problemId`	Yes

TDQS

B3.1/5.0

Behavior3/5

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

Discloses that answers are hidden and returns a sessionId for subsequent interactions. Lacks disclosure of potential side effects (e.g., state changes) or required permissions, but for a simple create action, basic transparency is met.

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?

Two concise sentences front-load the action and return values. Efficient but could be slightly more structured with explicit parameter description.

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?

Covers core purpose and return values, but missing details like parameter semantics and usage context. With one param and no output schema, the description is adequate but has clear gaps.

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% and the description does not explain the 'problemId' parameter (e.g., how to obtain it, expected format). The mention of 'stored problem' is too vague to aid in parameter selection.

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 action ('Begin a practice session'), the object ('stored problem'), and distinguishes from sibling tools by highlighting the session creation and return of a sessionId for interactive use.

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 explicit guidance on when to use this tool versus siblings like 'get_hint' or 'submit_solution'. The context implies it is for initiating a session, but no when-not conditions or prerequisites are mentioned.

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

submit_solutionSubmit solutionA

Record a solution attempt. In v1 judging is agent-side: YOU evaluate the code against the examples + referenceApproach and pass your verdict ('pass'/'fail') plus feedback. A 'pass' marks the session solved.

ParametersJSON Schema

Name	Required	Default
`code`	Yes
`verdict`	Yes
`feedback`	No
`language`	No	typescript
`sessionId`	Yes

TDQS

A3.6/5.0

Behavior3/5

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

Without annotations, the description carries the full burden. It discloses that passing a 'pass' verdict marks the session solved, implying state modification. However, it does not mention side effects on failure, permissions, or rate limits.

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?

Two sentences efficiently convey the purpose and key detail about agent-side judging. Every sentence adds value with no wasted words.

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 5 parameters, 3 required, and no output schema, the description is too sparse. It lacks details about input constraints, expected behavior on failure, and return value, making it incomplete for an agent.

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 0%, so the description must compensate. It explains the 'verdict' and 'feedback' parameters but does not clarify 'sessionId', 'code', or 'language', leaving some gaps.

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 records a solution attempt and explains the agent-side judging process. It distinguishes itself from sibling tools like 'get_hint' or 'next_step' by focusing on submission and evaluation.

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 use when the agent has evaluated a solution and wants to record the verdict, but it does not explicitly state when to use it versus alternatives or provide any exclusions.

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.

7 tool updatesv0.1.0Jun 28, 2026
- First observedexplain_concept
- First observedgenerate_problem
- First observedget_hint
- First observednext_step
- First observedprogress
- First observedstart_session
- First observedsubmit_solution

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

A3.9/5.0

Scored 2026-06-28 21:25 across 7 tools

Disambiguation5/5

Each tool targets a distinct action in the learning workflow—explain, create, hint, step, progress, session, submit—with no overlap.

Naming Consistency5/5

All tool names follow a consistent verb_noun snake_case pattern (e.g., explain_concept, start_session).

Tool Count5/5

Seven tools is well-scoped for a learning MCP server, covering concept recording, problem generation, session management, hints, and progress tracking.

Completeness4/5

The core learning loop is covered, but there is no tool to list or browse existing problems, which agents might need to select a problem for a session.

Maintenance

ActivityMaintained

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Related MCP Connectors

driflyte-mcp-server
com.driflyte
Driflyte MCP server which lets AI assistants query topic-specific knowledge from web and GitHub.
Search Web Scraping Knowledge & Memory
211
try B
md.install
Create guides as MCP servers to instruct coding agents to use your software (library, API, etc).
Documentation Access Developer Tools Coding Agents
132
agentwork-mcp A
io.github.ferm-ai
Official MCP server for Agentwork — delegate tasks to AI agents with human-in-the-loop
Agent Orchestration Autonomous Agents App Automation
2
ArcAgent MCP
io.github.araujota
ArcAgent MCP server for bounty discovery, workspace execution, and verified coding submissions.
Autonomous Agents Code Execution Coding Agents
22

Related MCP Servers

multivon-mcpofficial
AI & Machine Learning Testing & QA Tools
multivon-ai
A
license
A
quality
A
maintenance
MCP server that gives AI coding agents direct access to evaluation tools.
Updated 4 days ago (2026-09-17 01:56 UTC)
23
Apache 2.0
LeetCode MCP Server
Code Execution Developer Tools
AHM215
F
license
A
quality
D
maintenance
An MCP server that provides tools to interact with the LeetCode API, enabling problem fetching, code template generation, and solution execution/submission.
Updated a year ago (2025-10-07 22:55 UTC)
7
1
-
mcp-taskflow
Project Management Autonomous Agents Research & Data
CalebGerman
A
license
B
quality
C
maintenance
A local MCP server that gives AI agents structured task planning, execution tracking, and guided research workflows.
Updated 7 months ago (2026-02-10 16:27 UTC)
16
6 npm
MIT
mcdev-mcp
Games & Gamification Code Analysis Autonomous Agents
use-ai-for-mc
A
license
A
quality
A
maintenance
An MCP server that empowers AI coding agents to work effectively with Minecraft mod development, providing static analysis of decompiled source code and runtime interaction with a running Minecraft instance.
Updated 20 days ago (2026-08-31 10:27 UTC)
31
97 npm
14
MIT

learn-mcp

Install

From source (development)

How a session goes

Tools

Storage

Status

Development

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

multivon-mcpofficial