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., "@the-teacher help me learn guitar chords through the verified loop"
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.
Run learning as a verified loop: interview to build a detailed Target (your goal as observable claims), derive a Path to close the gap, learn through teach → lab → test → gate per claim, get cold-examined by an adversarial verifier, and raise the Target once you match it. A generic engine; ships with a guitar-learning example.
It's a small MCP server + Claude Code skill. The coaching agent teaches; a separate fresh-context examiner subagent grades — so the teacher never certifies itself.
python3 -m venv .venv && .venv/bin/pip install "mcp[cli]" pytest
.venv/bin/pytest # all green
THE_TEACHER_STORE=./store.local.json .venv/bin/python server.pySee Install below to add it to Claude Code.
Related MCP server: Rework
The repo is its own plugin marketplace, so Claude Code can install the server and the skill
together. Requires uv on your PATH (it pulls the mcp dependency
on the fly — no venv to manage).
/plugin marketplace add outlast85/the-teacher
/plugin install the-teacher@the-teacherThe coaching skill is then available as /the-teacher:teacher.
If you'd rather wire it up by hand (or don't use uv):
git clone https://github.com/outlast85/the-teacher.git
cd the-teacher
python3 -m venv .venv && .venv/bin/pip install "mcp[cli]"
# 1) register the MCP server (per-user; the `--` separator is required)
claude mcp add --transport stdio the-teacher -- "$PWD/.venv/bin/python" "$PWD/server.py"
# 2) install the coaching skill
mkdir -p ~/.claude/skills/teacher && cp skills/teacher/SKILL.md ~/.claude/skills/teacher/SKILL.mdThere is no global MCP list — registration is per-user and local. Confirm with
claude mcp list.
First run — the coach calls status(), and if no Target is set it interviews you
first: it probes your real goal, decomposes it into 2–6 claims with observable
pass_criteria, tags each claim needs_lab (runnable/software claims require lab evidence to
pass), dispatches a fresh-context subagent to review the drafted Target for specificity, then
calls set_target. A detailed Target is required before any teaching begins.
Teach → lab → test → gate per claim — for each module the coach teaches the concept,
runs a lab if needs_lab=true (recording evidence with record_progress), asks you to
explain the claim cold, dispatches a fresh-context examiner subagent to grade blind, and calls
record_verdict. A needs_lab claim with no logged lab evidence is coerced to non-pass by
the server even if the examiner says passed. The claim stays in derive_path until it
genuinely passes the gate.
Raise the Target — when status().matched is true, the coach congratulates you and
offers a harder Target, restarting the loop.
The examiner is deliberately adversarial (default-to-not-ready, high field standard). What makes the verdict independent of the teacher is context isolation — and that's the only mechanism:
The verifier is a fresh-context examiner subagent. The coach asks the learner to explain the
module cold, then dispatches a SEPARATE subagent (same model, clean context) whose prompt
contains ONLY the claim, the pass criteria, the learner's explanation, and any lab evidence —
never the coaching conversation. Because that examiner never saw the context it would otherwise
be anchored on, the grade is genuinely decorrelated: real maker/checker, not Reflection. The
coach records it via record_verdict(..., verdict_source="fresh-context"). This works for
any subject, needs zero config, no second model, and no external service.
Discouraged — same-context: inline grading in the same coaching conversation. If ever
used, it's recorded as verdict_source="same-context" and status() raises an
only_same_context warning when a match is backed solely by it. This is the weak-verifier
case; avoid it.
matched in status counts fresh-context verdicts. The server itself never calls any model —
all grading is done by the subagent inside your own client.
Resource URIs use the theteacher:// scheme (e.g. theteacher://target,
theteacher://path, theteacher://progress).
Your Target/Path/progress live in a local JSON store (~/.the-teacher/store.json by default,
overridden by THE_TEACHER_STORE) that is gitignored. The repo ships only the generic
example. No personal data is ever committed.
Derive modules for claims not yet passed.
Inputs: no named parameters.
Load a Target from a JSON template file and set it as the current target. Defaults to the shipped example (zero personal data). Validates via build_target.
Inputs: path.
Log a learning attempt + evidence (durable). Validates that a target exists and module_id is a known claim — same guard as record_verdict.
Inputs: module_id (required), status (required), evidence.
DEFAULT path: record the cold examiner's verdict.
The skill instructs the coaching agent to dispatch a FRESH-CONTEXT examiner SUBAGENT (the Agent/Task tool — same model, clean context) whose prompt contains ONLY the claim statement, the pass criteria, and the learner's explanation (NOT the coaching history), then call this tool with verdict_source="fresh-context" (the default). Because the examiner never saw the coaching context, the grade is genuinely decorrelated — real maker/checker, not Reflection.
verdict_source must be one of:
"fresh-context" (default; the decorrelated examiner subagent)
"same-context" (DISCOURAGED inline grading; status() flags matches backed only by it)
A passed=True verdict with score < 0.7 is coerced to a non-pass. A passed=True verdict for a needs_lab claim with no logged lab attempt (evidence) is also coerced to a non-pass.
Inputs: module_id (required), passed (required), score (required), gaps, +2 more.
Store the goal as a spec (claims + pass criteria).
Inputs: title (required), claims (required).
Report coverage against the Target; matched = all claims have a passing (fresh-context) verdict. Warns via only_same_context if a match is backed solely by discouraged inline grading.
Inputs: no named parameters.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
Scored across 6 tools
Each tool has a distinct purpose: derive_path generates learning paths, load_target loads targets, record_progress logs attempts, record_verdict records exam verdicts, set_target stores goals, and status reports coverage. No overlap.
Most tools follow verb_noun pattern (derive_path, load_target, record_progress, record_verdict, set_target). 'status' is a single noun but is a common exception.
Six tools is well-scoped for the domain of managing learning targets and progress. Neither too few nor too many.
The tool set covers the full workflow: setting targets, loading them, deriving paths for uncovered claims, recording progress and verdicts, and reporting status. No obvious gaps.
A sourced learning map your AI places you on: finds gaps you can't name, teaches step by step.
Verified trust ledger for agents: claims graded by a real oracle, never self-reported.
Verifier-grounded AI promotion gates, disposable report cards, and signed PASS/HOLD/BLOCK receipts.
Training gym where AI assistants practice real tasks and earn signed, verifiable scores.
