Model

Runtime vs LLM

The LLM is the interface: it explains, asks questions, adapts tone, writes examples, and summarizes the session. Tutor MCP is the runtime: it stores state, chooses the next activity, validates evidence, detects gaps, and decides when to review or move on.

The useful mental split: Tutor MCP decides what and why. The LLM decides how to say it.

Start

First session

After connecting the MCP server, start with a goal that is concrete enough to decompose into concepts. The assistant should create a domain if none exists.

Use Tutor MCP.
I want to learn Go concurrency in three weeks.
Create a learning domain, start with a short diagnostic, and keep session memory enabled.

A good first run usually calls init_domain, then get_next_activity. If the assistant skips the runtime and starts tutoring directly, ask it to use Tutor MCP explicitly.

Your moves

Ask for what you need

You do not have to accept the default path silently. Ask for review, a different pace, a harder challenge, a safer exercise, a different style, or a visible explanation of the plan. The assistant should use learning_negotiation, transfer_challenge, feynman_challenge, or get_olm_snapshot rather than inventing a plan from scratch.

Use Tutor MCP.
Show me why you picked this activity in plain language.
Then offer one easier option, one harder option, and one review-only option.

Prompts

Prompt examples

These prompts are meant for the chat connected to Tutor MCP. They name the runtime explicitly so the assistant knows to call the tools instead of improvising a normal tutoring chat.

Start a new goal

Use Tutor MCP.
I want to learn SQL window functions for analytics interviews in two weeks.
Create the domain, start with a diagnostic, and keep the first exercise short.

Resume where you stopped

Use Tutor MCP.
Resume my Go concurrency track from the last session.
Read my learner context and memory before choosing the next activity.

Ask for review instead of new material

Use Tutor MCP with review intent.
Pick the concept most at risk of forgetting and give me one calibrated exercise.
Record the result after I answer.

Change the teaching style

Use Tutor MCP.
Keep the same activity, but teach it Socratically.
Ask one question at a time and do not reveal the answer until I try.

Make the plan transparent

Use Tutor MCP.
Show me why this activity was selected in learner-friendly terms.
Then offer one safer option and one harder option.

Correct memory

Use Tutor MCP.
You remembered that I prefer visual explanations, but that is only true for math.
Update learner memory so programming sessions use concrete code examples first.

End

Close a session

A clean close preserves continuity. The runtime returns a recap brief and asks the LLM to write the session summary through update_learner_memory. It can also collect an if-then implementation intention for the next session.

Close the Tutor MCP session.
Summarize what changed, ask me when I will practice next, and save the session memory.

Under the hood

Conversation loop

get_learner_context

Open with context

The assistant reads active domains, recent history, concept states, and active misconceptions before tutoring.

get_next_activity

Let the runtime choose

Tutor MCP selects the next activity, phase, concept, difficulty, motivation brief, and episodic context.

record_interaction

Record the outcome

The assistant persists success, error type, hints, initiative, rubric evidence, and interpretation notes.

record_session_close

Close cleanly

The runtime returns recap signals and a memory-writing request so the LLM can store a factual session summary.

The loop only works if outcomes are recorded. If the assistant gives exercises but never calls record_interaction, the runtime cannot update mastery, retention, calibration, or misconceptions.

Signals

Progression signals

Tutor MCP combines algorithmic signals with narrative traces. The algorithms keep the schedule rigorous; the memory layer gives the LLM enough context to avoid generic teaching.

Signal	Source	Learner-facing effect
Mastery	BKT, PFA, evidence gates	Whether a concept is ready, shaky, or needs stronger proof.
Retention	FSRS	When to review before forgetting becomes expensive.
Ability	IRT, Rasch/Elo	Whether the exercise difficulty matches the learner.
Structure	KST, prerequisites	Which concepts can unlock without skipping foundations.
Metacognition	Affect, calibration, autonomy	How much support, prediction, or fading the tutor should use.
Narrative	Sessions, concept notes, archives	What happened, what clicked, what remains uncertain, and what to verify.

Memory

Learner memory

The memory layer is Markdown on your server. It is designed for factual summaries, not private diary prose. Session files capture what happened; concept notes track durable observations; pending memory holds unconfirmed hypotheses; archives consolidate longer periods.

get_memory_state
read_raw_session(timestamp: "2026-05-14T16:30:00Z")
update_learner_memory(scope: "concept", concept_slug: "goroutines", operation: "replace_section", section_key: "Current state", content: "...")

Ask the assistant to mark uncertain observations as hypotheses. Tutor MCP exposes pending memory so the LLM can use it without treating it as established truth.

Operate

Privacy & backups

Your LLM provider or local client keeps its own chat transcript. Tutor MCP keeps the learning state you preserve through MCP calls. Back up DB_PATH for algorithmic state and TUTOR_MCP_MEMORY_ROOT for Markdown memory.

For sensitive use, self-host behind HTTPS, set TRUSTED_PROXY_CIDRS, keep TUTOR_MCP_MEMORY_ENABLED=on only when you want narrative memory, and periodically review the Markdown files because they are intentionally human-readable.