learning-mcp
Click on "Deploy 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., "@learning-mcp Teach me about Postgres indexes"
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.
learning-mcp
An MCP server that teaches you a topic by enforcing a pedagogical workflow instead of suggesting one.
Ask a chat model to "teach me Kafka step by step" and it will agree, then quietly compress five steps into one. That isn't disobedience — it's what happens when the whole plan sits in context at once: the model can see step 5 while working step 1, so it hedges step 1 toward the finish and merges anything it judges redundant.
This server holds the steps instead. The next instruction does not exist in the model's context until it has handed back a valid artifact for the current one. Sequencing stops being a request and becomes a data dependency.
The workflow
research -> decompose -> drill (loop) -> doneResearch — build a comprehensive, cited picture of the topic.
Decompose — break it into atomic elements, each with its prerequisites. The result is a DAG, not a list.
Drill — the loop that actually teaches. One element at a time, chosen by what's unlocked, due, and weakest.
Related MCP server: LearnFlow AI
What makes it a tutor rather than a quiz
Retrieval practice over re-reading. The default action is to ask, wait, and grade. Explanation is the fallback after a miss, not the main event.
Escalating demand. Each element moves recall → explain_back → apply as
it becomes familiar. You have to produce the idea, not recognize it.
Prerequisites are enforced. An element is only drillable once everything it depends on is mastered, so you're never quizzed on consumer groups before partitions.
Interleaving comes free. Once several elements are unlocked, the scheduler alternates rather than drilling one to exhaustion.
Spacing, and a gate that resists cramming. Reviews follow an SM-2 interval ladder. Mastery additionally requires that one success landed a full day after a previous one — three right answers in a single sitting is short-term memory, and the gate says so.
The answer has to be yours. During a drill the server suspends mid-call to collect your answer, which reaches the model as a tool result it did not author. It cannot ask a question and answer it on your behalf.
Running it
Requires MCP SDK 2.0+ — the drill loop uses MCPServer and the
Resolve/Elicit round trip, neither of which exists in the 1.x FastMCP API.
Locally (start here)
This is the right choice for almost everyone. The server runs as a subprocess of your client, your data stays on your disk, and there is nothing to secure.
pip install learning-mcp # or: pip install git+https://github.com/ryantthomas/learning-mcp
claude mcp add learning -- learning-mcpThen ask it to teach you something.
With Docker
docker build -t learning-mcp .
docker run -p 8000:8000 \
-v learning-data:/data \
-e LEARNING_MCP_TOKEN="$(openssl rand -hex 32)" \
learning-mcpThe volume is not optional. Every topic, element and review date lives in one
SQLite file under /data. Without a persistent volume the container starts
empty every time, and you won't notice until the day you come back to review.
On your own cloud
The Dockerfile is the only deploy artifact, deliberately — it works on Fly, Railway, Render, Cloud Run, or any VPS, and locks you into none of them. Two things actually matter:
Attach a persistent volume and point
LEARN_HOMEat it (the image defaults to/data). Platforms with ephemeral filesystems will silently discard everything on restart.Set
LEARNING_MCP_TOKEN. The server refuses to start on a non-loopback interface without one. That's a deliberate fail-closed, not an obstacle to work around — an open URL is a read/write handle on your entire learning history.
$PORT is honoured, so most platforms need no further configuration.
Authentication, honestly
LEARNING_MCP_TOKEN enables Authorization: Bearer <token> on the HTTP
transport. Configuration is per-instance, and each person runs their own — there
is no multi-user mode and no notion of accounts.
Client | Works with a bearer token? |
Local stdio (Claude Desktop, Claude Code) | N/A — no network exposure |
Claude Code against a remote URL | Yes, via |
Other CLI / custom MCP clients | Yes, if they can send a header |
claude.ai and the mobile apps | No — the custom connector UI only accepts OAuth |
That last row is worth reading twice if your goal is studying on your phone.
Claude's custom connector settings expose Authorization URL, Token URL, Client
ID and Client Secret — there is no field for a static token or custom header. A
bearer-token server cannot be registered there. Making that work needs a real
OAuth authorization server; the SDK supports it via auth_server_provider, but
this project doesn't implement one yet.
Where your data lives
Everything is under ~/.learn (override with LEARN_HOME). SQLite is the
source of truth; markdown is a projection of it, so a topic stays readable and
greppable without the tool.
~/.learn/
learn.db
topics/kafka/
research.md
elements/01-partitions.md
progress.mdA hosted instance moves this off your machine. The markdown mirror ends up on the server, where you can't grep or commit it. If those local files are the point for you, run stdio locally instead of deploying.
The schema is deliberately graph-shaped — prerequisites and concepts are their
own tables, never JSON on a row — so a Neo4j projection later is an export
rather than a rewrite. concepts is global while elements are topic-scoped,
which is the seam that will let "partitioning" learned under Kafka count for
itself again under Kinesis.
Design
The pedagogy lives in steps.py, mastery.py, and scheduler.py, none of
which import mcp. That's deliberate: the teaching logic is a plain Python
library that happens to be served over MCP, so it can be unit-tested without a
model in the loop and re-fronted without a rewrite.
server.py is a thin adapter. Every advance requires the previous step's
artifact as an argument — the model cannot obtain step N+1 without paying for
step N.
Development
pip install -e ".[dev]"
pytestThe two tests worth knowing about, because they encode the whole point:
the gate — a malformed artifact must not advance the phase
concealment — a step's response must not contain any later step's text
License
MIT.
Available Tools
7 toolsask_userA
Put your drill question to the user and return their answer.
Prefer this over asking in chat. The answer comes back to you as a tool result, which means it is genuinely the user's, and the question is recorded verbatim next to whatever verdict you give it.
If this tool errors because the client can't prompt the user, ask your
question in the chat instead and pass both question and answer to
grade_drill.
Args: session_id: From start_topic. element_id: From next_drill. question: The question, worded exactly as the user should see it.
Inputs: question (required), element_id (required), session_id (required).
grade_drillA
Record how the user did, and schedule when the element comes back.
A question has to exist before a verdict can attach to it: either you asked
through ask_user, or you asked in chat and pass question and answer
here. Grading an element you never actually asked about is rejected.
Args: session_id: From start_topic. element_id: The element that was drilled. verdict: "correct", "partial", or "incorrect". See the standing rules on strictness — when genuinely torn, "partial" is the honest answer. answer: What the user said, in their words. question: Only when you asked in chat instead of through ask_user. notes: What they missed, in a phrase. Worth filling in — it's the only record of how they were wrong.
Inputs: verdict (required), element_id (required), session_id (required), notes, +2 more.
next_drillA
Get the next element to drill and the kind of question to ask about it.
The choice accounts for prerequisites, review schedule and relative weakness, so take what you're given rather than picking a topic yourself. Returns the element's own explanation for grading against — do not show that to the user unless they get the question wrong.
Args: session_id: From start_topic.
Inputs: session_id (required).
resumeA
List topics with elements due for review right now.
Call this when the user opens a session without naming a topic, or asks what they should study. Reviewing something about to decay beats starting something new, so offer these before suggesting a fresh topic.
Inputs: no named parameters.
start_topicA
Begin learning a topic, or rejoin one already in progress.
Call this first, whenever the user wants to learn or study something. Returns the instruction for the current step and nothing about later ones.
Re-calling this for a topic already underway resumes it rather than starting over — mastery is tracked per element, so a second pass would split the record rather than double it.
Args: topic: What to learn, e.g. "kafka consumer groups" or "options pricing".
Inputs: topic (required).
statusA
Where this topic stands: phase, mastery counts, and what's still locked.
Useful for orienting mid-session or after a break. Report it to the user as progress, not as a schedule — don't read out due dates.
Args: session_id: From start_topic.
Inputs: session_id (required).
submit_stepA
Hand in the current step's work and receive the next instruction.
This is the only way to advance. The artifact is checked for shape before the phase moves, so a thin or malformed submission comes back with a reason and the phase is unchanged — fix it and submit again rather than continuing.
Args: session_id: From start_topic. artifact: Whatever the current instruction asked you to produce — the research markdown as a string, or the decomposition as a list of {name, explanation, prereqs} objects.
Inputs: artifact (required), session_id (required).
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
TDQS
Scored across 7 tools
Each tool targets a distinct stage of the learning workflow: starting/resuming a topic, submitting work, drilling, checking status, asking questions, grading, and listing due reviews. There is no meaningful overlap.
The naming is mostly verb_noun snake_case (start_topic, submit_step, ask_user, grade_drill), but 'next_drill' and 'status' break the pattern, and 'resume' is a bare verb. Overall the style is consistent and readable.
Seven tools is well-scoped for a focused learning assistant. Each tool serves a clear purpose and none feel superfluous.
The tool set covers the full learning lifecycle: initiating a topic, advancing through steps, drilling, grading, assessing status, and handling due reviews. No obvious gap in the intended workflow.
Maintenance
Related MCP Connectors
An MCP server for deep research or task groups
Educational MCP server with 17 math/stats tools, visualizations, and persistent workspace
Open-source AI courses taught by your AI tutor in conversation, with progress saved by MCP tools.
Related MCP Servers
- AlicenseBqualityDmaintenanceAn MCP server for tracking student learning via a knowledge graph, with spaced repetition scheduling and intelligent queries to identify gaps, misconceptions, and optimal next steps.71MIT
- AlicenseNot gradedqualityDmaintenanceAI-powered MCP server that transforms learning by finding best YouTube tutorials, generating personalized learning paths, and tracking progress for any tech skill.11MIT
- AlicenseNot gradedqualityDmaintenanceAn MCP server and CLI for step-by-step learning, enabling humans and agents to learn subjects like language tutoring through a structured prompt system.1Apache 2.0
- AlicenseNot gradedqualityCmaintenanceAn MCP server that provides an open, local-first record of a child's learning, enabling an AI tutor to read, teach from, and update the child's knowledge, interests, and progress.1Apache 2.0