Codemm
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| CODEMM_HOME | No | Overrides the location where Codemm stores your data (tracks, courses and attempt history). By default this data lives in ~/.codemm. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This computer has no container runtime (Docker or Podman) installed and no wasmtime, so no track can run here until one is installed: tell the learner.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_tracksA | List installed tracks (language or framework environments) with their versions and test styles. |
| save_trackA | Install a track: track.yaml, a Dockerfile (a WASI track has none) and probe/ files. Building the image runs the Dockerfile WITH network access (a WASI track downloads its toolchain instead), so only install tracks the learner agrees to. Codemm then runs the probes with the network off and installs the track only if every gate passes; otherwise it returns what failed. |
| save_roadmapA | Create or update the course roadmap and make it active in this workspace. YAML with title (the course's name in a few plain words, at most 60 characters), goal, track (id@version; none for quiz, optional for none), style (io|unit|quiz|none), concepts [{id, title, requires, practice?, pitfalls?, refs?}] and optional sources [{title, url}]; refs are indexes into sources. Keep concept ids stable when you edit it. |
| get_roadmapC | The course roadmap: title, goal, track, style and concepts with their prerequisites, and the track's contract once it's set up. |
| next_stepA | What to do next: setup (install the track), practice an existing exercise, review a mastered concept on an exercise (a check keeps it mastered), author a new one (concept, difficulty, style, track; review: true when it's for a review), learn (lessons only), stuck, or done. On learn, lesson is null when a lesson needs writing, otherwise the earliest unread lesson id. On practice and author, lesson is null when the concept needs a lesson first, or the id of a lesson the learner hasn't read yet; teach before the activity until it's gone. |
| save_exerciseA | Author tool. Save an exercise (exercise.yaml, README.md, starter/, solution/, mutants//, tests/visible/, tests/hidden/; a quiz: exercise.yaml, README.md, quiz.yaml). Codemm runs every gate and stores it only if all pass. Returns only the exercise id; report nothing else to the tutor. |
| get_exerciseA | Show an exercise to the learner: statement, the file(s) to edit, visible tests and hint; for a quiz, its questions and choices, never the key. |
| checkA | Grade the learner's current code against all tests and record the attempt. Hidden tests report only pass or fail. A quiz is graded once every question is answered, and only its first check is recorded. |
| progressB | Course style, mastery, difficulty and covered per concept, and the next step. Covered means at least one lesson, all read. |
| save_lessonA | Save a lesson for one roadmap concept: Markdown (at most 64 KB) the learner reads before the activity, and up to 5 runnable examples. Each example is a file map with exactly the track's learner files (for unit, plus tests/ files); Codemm runs each in the sandbox with no input and it must exit 0. Place example N in the Markdown as a fenced block with info string example whose only line is N. An example that needs input goes in a plain code block. Diagrams and charts go in fenced blocks with info string mermaid (flowchart, sequenceDiagram, stateDiagram-v2, classDiagram, pie, xychart), only when a picture teaches better than words; give each an accTitle and accDescr for screen readers. The id must be new in the course. |
| get_lessonB | Read a lesson and the learner's notes on it. Records nothing. |
| mark_lesson_readA | Record that the learner has read a lesson. Call it only after the learner says they've read it. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 12 tools
The save/get/list pairs (track, roadmap, exercise, lesson) are cleanly separated by resource and direction, and authoring vs. learner-facing tools are clearly distinguished. The one weak boundary is next_step vs. progress, since progress explicitly also returns 'the next step' and both report state, which could cause an agent to pick the wrong one when asked 'what should I do now?'.
Seven tools follow a strict verb_noun snake_case pattern (save_track, get_roadmap, list_tracks, save_exercise, get_exercise, save_lesson, get_lesson) plus mark_lesson_read. The remaining three (check, progress, next_step) break the pattern with bare verbs/nouns, but they remain readable and domain-obvious rather than chaotic.
Twelve tools is well within a healthy range and splits naturally into track/roadmap setup, authoring (exercise, lesson), and learner interaction (get_exercise, check, get_lesson, mark_lesson_read) plus guidance state. Each tool maps to a distinct step in the course lifecycle, with only slight redundancy between next_step and progress.
The surface covers the full authoring-and-learning loop: install/list tracks, save/get roadmap, author/get/grade exercises, save/get/mark lessons, and track progress. Minor gaps exist — no delete or uninstall operations for exercises, lessons, or tracks, and no way to enumerate existing exercises or lessons (agents must rely on next_step/progress to discover them).