
Dsa Coach Mcp
io.github.aaryagodbolePublished by GitHub account aaryagodbolev0.2.0Updated Nov 3, 2026
DSA coach for LeetCode, Codeforces and more: spaced-repetition revision and a mistake journal.
Overview
Dsa Coach's local MCP server; no sign-in required; STDIO.
No AI overview yet: these facts come from the registry entry and the server itself.
Installation
In SourceWeft
- Open Dsa Coach Mcp in the dashboard and add it to a workspace.
- Enable the server for the chats that should use its tools.
Desktop only via STDIO. STDIO servers start a local process, so they need the SourceWeft desktop host.
Other MCP clients
Follow the launch instructions in the repository.
README
dsa-coach-mcp
[CI] [PyPI] [Python 3.12+] [License: MIT]
An MCP server that turns your LeetCode and Codeforces history into a DSA coach inside Claude, Cursor or any MCP client: see where you stand across platforms, get problems to try next, and revise what you solved on a spaced-repetition schedule, with a mistake journal that remembers why you got things wrong and builds your next practice set around it.
[dsa-coach-mcp driven over stdio on live LeetCode and Codeforces data]
A real session, recorded by examples/demo.py: it starts the server over stdio and calls its tools on live data.
Why
Practice data is split across sites, and each grades difficulty its own way (LeetCode's Easy/Medium/Hard, Codeforces' 800-3500 ratings). Most trackers count problems; few tell you what you are forgetting. This server puts both platforms behind one interface and schedules revision with FSRS, so the model you already talk to can coach you.
FSRS predicts the chance you still remember each problem and brings it back just before
that chance drops below 90%. In the open
spaced-repetition benchmark
over ~10k Anki collections, FSRS predicted recall better than SM-2 for the large
majority of users. Once you have a review history, personalize_schedule fits its
parameters to how fast you forget.
Counting solved problems hides the real signal: the same few mistakes, repeated. Every review can carry the mistakes behind it, and the model turns those patterns into practice sets and revision quizzes aimed at exactly what you keep missing.
Design
The server returns data, not decisions. It never hardcodes what counts as a weak topic or the next level up; the model reads your profile and the platform's own vocabulary and decides.
- Adapters translate one platform's API into shared models (
Problem,Profile,PlatformInfo). Nothing outside an adapter names a platform. - Data comes from the platforms. Tags and levels are read from each platform's
API, and a review takes the problem's title, link and tags from the platform rather
than from the model, so nothing in your history is invented. Platforms' own tag
lists are incomplete, so
search_problemsaccepts a tag outside them and only reports it when nothing matched. - Profiles say what they can't see. Each profile carries
limitations, e.g. LeetCode only exposes your 20 most recent accepted submissions publicly.
Tools
Prompts
Dashboard
show_dashboard is an MCP App:
hosts that support them (Claude, Claude Desktop, VS Code Copilot, Goose and others) render
it inside the conversation; every other host gets the same data as the tool's result.
The view is one self-contained HTML file with no external scripts, follows the host's
light or dark theme, and talks to the host over the MCP Apps postMessage protocol.
[dsa-coach dashboard, dark theme] [dsa-coach dashboard, light theme]
Rendered from sample data by examples/dashboard_host.py, which plays the host's side of the protocol.
Any platform
LeetCode and Codeforces have adapters that read from their APIs. Every other platform
works through the page you are looking at: pair this server with a browser MCP server
such as Playwright MCP in extension mode,
which lets the model read the tab open in your own browser, logged in. The model reads
the problem page and calls record_problem with its URL, title, tags and difficulty;
from then on it is reviewed, scheduled and journaled like any other problem.
No platform is listed in the code: the platform is the problem URL's host, and its
problem id is the URL's path. Problems recorded this way are marked
"source": "reported", because they come from a page the model read rather than from
the platform's API, and a host that has an adapter is always sent to its adapter.
Mistake journal
There is no fixed list of mistake types. The model labels each mistake in a few words and is shown every label used before, so it reuses yours instead of inventing new ones; your journal's vocabulary grows from your own reviews. The server only stores and counts them; spotting the pattern is the model's job.
Install
Requires uv.
Claude Desktop: add to claude_desktop_config.json:
Claude Code:
Cursor: same command and args as above in .cursor/mcp.json.
Agent skill
skills/dsa-coach/SKILL.md tells the agent when to reach
for these tools and how to use them well: how to rate a review, to reuse existing
mistake labels, and to record problems from other platforms only from a page it read.
For Claude Code, copy it into your skills:
Configuration
To personalise the schedule, install the optimizer extra (it pulls in PyTorch):
uvx --from 'dsa-coach-mcp[optimizer]' dsa-coach-mcp.
Privacy
No login and no API keys. The server only calls the platforms' public APIs with the handles you give it, and revision cards stay in a local SQLite file.
Adding a platform
- Write
src/dsa_coach_mcp/platforms/<name>.pywith a class implementingPlatformAdapter:name,describe(),profile()andsearch(). - Add the class to
ADAPTERSinplatforms/__init__.py. - Add tests with a mocked API, like
tests/test_codeforces.py.
The server and tools need no changes.
Evals
Unit tests check the code; evals/ checks whether a model can actually
coach with these tools. A model drives the real server over the MCP protocol, against a
fixture world (one practice platform, a seeded history, a fixed clock), on tasks such
as planning from a profile, logging a review with its mistakes, reusing an existing
mistake label, recording a problem from another platform, and staying silent when no
tool is needed.
Grading is deterministic, with no LLM judge: each task lists the tool calls it expects with predicates on their arguments, the tools it must not touch, and a call budget. A run reports pass rate, tool-selection accuracy, argument accuracy, tool error rate, calls per task and token usage.
The model is configuration, not code. Any API that speaks the chat completions format works, whether a hosted free tier, a paid API or a model served on your own machine:
The loop talks to models through a small AgentBackend interface
(evals/backends/base.py); an API with a different wire
format is one more backend module. Runs never start on their own: run it locally, or
start the Agent evals workflow from the Actions tab after setting the
EVALS_BASE_URL and EVALS_MODEL repository variables (and an EVALS_API_KEY secret
if your API needs one). The graders, the fixture, the loop and the backend are
unit-tested in CI without calling any model.
Development
Re-record the demo at the top of this page against live data:
Tests never hit the network: adapters are tested against mocked API responses. See CONTRIBUTING.md.
License
Source: README.md at commit 8a4bf99
Tools
0Version history
1- v0.2.0LatestNov 3, 2026
Score
50% of the applicable checks met
How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.
- Reached in the last 30 days25 pts
Keep the endpoint answering the MCP handshake; SourceWeft probes it every 30 days.
- Auth declared10 pts
Declare the credential headers in the registry entry, or keep the endpoint answering the probe so its auth can be classified.
- Tools listed15 pts
Answer tools/list without a credential, or ship a package that starts in a sandbox without one.
- DescriptionRequired15 pts
- Logo10 pts
- Documentation15 pts
- License10 pts