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: Sensory-Grounding MCP
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose side effects, permissions, or outcomes of deriving modules. It implies a transformation but lacks detail.
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?
The description is a single, concise sentence. While efficient, it could benefit from additional structure or detail without being verbose.
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?
Given no annotations and no output schema, the description is the sole source of information. It fails to explain what 'derive' means, what 'modules' are, or the outcome, leaving significant gaps.
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?
There are zero parameters, so the schema alone provides no meaning. The description adds the context of the action on specific claims, which is necessary for understanding the tool's purpose.
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?
The description clearly states the verb 'derive' and the resource 'modules for claims not yet passed'. It distinguishes from siblings which focus on loading, recording, or status. However, 'derive modules' could be more specific.
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?
No guidance on when to use this tool vs. alternatives like load_target or status. The description does not specify context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | templates/example.json |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden. It discloses that the tool sets the current target and performs validation, but lacks details on side effects (e.g., overwriting), error handling, or access requirements.
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?
The description is two sentences with no filler. The first sentence states the core action; the second provides default and validation context. Every sentence is essential.
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?
For a tool with one parameter, no output schema, and no annotations, the description covers purpose, default, and validation. It could briefly mention return behavior, but overall it is adequate.
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?
Schema description coverage is 0%, so the description compensates by explaining the parameter as a file path for a JSON template and noting the default. This adds meaning beyond the schema, though it could clarify format constraints.
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?
The description clearly states the action 'Load a Target from a JSON template file' and 'set it as the current target', specifying the resource and outcome. It also distinguishes from siblings like set_target by mentioning file-based loading and validation via build_target.
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?
The description implies usage for loading a target from a file, with a useful default example. However, it does not explicitly state when not to use this tool or mention alternatives like set_target.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Log a learning attempt + evidence (durable). Validates that a target exists and module_id is a known claim — same guard as record_verdict.
| Name | Required | Description | Default |
|---|---|---|---|
| module_id | Yes | ||
| status | Yes | ||
| evidence | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses durability, validation of target existence, and module_id claim check. However, it omits side effects, error handling, and what 'durable' means operationally.
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?
Two sentences front-loaded with purpose. No redundancy. Could be slightly improved by separating the validation note more distinctly, but overall efficient.
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?
No output schema, so description should explain return value or outcome. It does not describe what happens after logging, error responses, or how to interpret results. Lacks detail for a tool with three parameters and validation.
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?
Schema coverage is 0%, and description only mentions module_id as a known claim. It does not explain status (possible values or meaning) or evidence (optional usage). The description adds minimal value beyond schema structure.
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?
The description clearly states the tool logs a learning attempt with evidence (durable). It specifies validation against a target and known claim, distinguishing from sibling 'record_verdict' by mentioning similar guard. However, the concept of 'learning attempt' 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.
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 'record_verdict' or 'status'. The mention of 'same guard as record_verdict' implies a shared validation pattern but does not clarify context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| module_id | Yes | ||
| passed | Yes | ||
| score | Yes | ||
| gaps | No | ||
| probe_followups | No | ||
| verdict_source | No | fresh-context |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description details the fresh-context mechanism and two coercion rules (score <0.7 and needs_lab with no evidence). Since no annotations are provided, the description fully discloses behavioral traits.
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?
The description is detailed and well-structured, with clear sections for purpose, mechanism, and parameter options. It is slightly verbose but every sentence adds value.
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?
Given 6 parameters with no schema descriptions and no output schema, the description covers the core behavior and coercion rules but omits details on module_id, gaps, and probe_followups. Adequate but not fully complete.
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?
The description adds meaning for verdict_source (explaining its two values) and for passed/score via coercion rules, but does not explain module_id, gaps, or probe_followups. Schema coverage is 0%, so the description partially compensates.
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?
The description clearly states the tool's purpose: 'record the cold examiner's verdict.' It explains the context of a fresh-context examiner subagent and differentiates from sibling tools by focusing on verdict recording.
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?
The description provides explicit guidance on verdict_source, recommending 'fresh-context' and discouraging 'same-context,' and notes that status() flags matches backed only by same-context. This helps the agent decide when to use each option.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Store the goal as a spec (claims + pass criteria).
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | ||
| claims | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully describe behavior. It only says 'Store', implying a write operation, but lacks details on whether it overwrites, requires permissions, or triggers side effects. The description is insufficient to understand the tool's impact.
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?
The description is a single sentence, which is concise, but it lacks structure and important details. It is front-loaded with the main purpose but the brevity sacrifices completeness.
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?
The tool has no annotations, no output schema, and 2 required parameters. The description is too brief; it does not explain return value or behavior when a target already exists. Given the complexity and missing structured information, the description is inadequate.
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?
Schema description coverage is 0%, so the description must compensate. It mentions 'claims + pass criteria', but 'pass criteria' is not a parameter; 'claims' is an array of items without type specification. The description adds minimal meaning beyond the parameter names.
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?
The description states the tool 'Store the goal as a spec (claims + pass criteria)', indicating a write operation for a goal. However, 'spec' is vague, and the mention of 'pass criteria' doesn't match the schema parameters. It does not differentiate from siblings like 'load_target' or 'record_progress'.
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?
No guidance on when to use this tool versus alternatives such as 'load_target' or 'record_progress'. There is no mention of prerequisites, context, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses a warning behavior (only_same_context for matches from discouraged inline grading), but does not state whether the tool is read-only, has side effects, or requires authentication.
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?
Two sentences: the first states the main action, the second adds an important nuance. No wasted words.
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?
For a tool with no parameters and no output schema, the description explains the core purpose and a behavioral caveat, but it does not describe the return value or format, leaving some incompleteness.
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?
The tool has no parameters; schema coverage is 100% (vacuously). Baseline for 0 params is 4, and the description does not need to add parameter semantics.
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?
The description clearly states the tool reports coverage against the Target and defines what 'matched' means. Sibling tools (derive_path, load_target, record_progress, record_verdict, set_target) perform different actions, so status stands out as distinct.
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?
The description implies usage when a coverage report is needed, but it does not explicitly state when to use this tool versus alternatives or provide exclusions. No guidance on when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0derive_pathload_targetrecord_progressrecord_verdictset_targetstatusScored 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.
Verifier-grounded AI promotion gates, disposable report cards, and signed PASS/HOLD/BLOCK receipts.
Verifies AI agent work end to end: real artifacts and outcomes checked, not self-reported success.
Architecture compiler for AI code. 11 tools, 92 actions, 872 Lean4 proofs, 100/100 self-cert.
Deterministic sealed verdicts on public claims and startup ideas (0-LLM claim-safety guardian).
