mltree-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| MLTREE_PROJECT | No | Path to the project directory. Equivalent to the --project <dir> flag. If unset, CLAUDE_PROJECT_DIR is used, then the server's current working directory. | |
| CLAUDE_PROJECT_DIR | No | Project directory set automatically by Claude Code for stdio servers. Used as a fallback when MLTREE_PROJECT and --project are not set. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| init_projectA | Create the .mltree/ store (pipeline.yaml, mltree.db, runs/) in the project root. Safe to call again. |
| add_stepB | Register a pipeline step (a node on the map), or update it if the name already exists. |
| connect_stepsA | Draw a directed edge source -> target. Both steps must exist; cycles are rejected. |
| get_pipelineB | Return the whole map: nodes (with params, script and latest run status), edges and a topological order. |
| log_runB | Record one execution of a step: params, metrics, artifacts and its parent run in the experiment tree. The versions (SHA-256) of the step's input and output files are recorded too, so later runs can tell when the data changed. |
| data_statusA | Data versions: the current SHA-256 of every step's input and output files, what the step's latest run used, and which inputs changed since (so the step is stale and should be re-run). Reads files only; runs nothing. |
| compare_runsA | Compare runs: params that differ (baseline -> each run), metrics side by side, data versions used, and a unified diff of the script snapshots of the first two runs. |
| add_noteA | Add a note to a step or a run, e.g. why a run failed, what a step assumes, or a conclusion from a comparison. Notes show in the viewer (where the user can edit them), in get_pipeline / list_runs and in the HTML export. |
| tag_runA | Add or remove tags on a run (e.g. 'baseline', 'best', 'final'). The tree can highlight runs by tag. |
| gnn_summaryA | GNN view of a step: the model architecture read statically from its script and imported project modules (conv layer types and counts, hidden sizes, heads, pooling, head, forward order; nothing is imported or run), dataset classes it constructs (TUDataset, MoleculeNet, QM9, OGB, DGL ...), and cached dataset stats (graphs, nodes/edges per graph, feature dims, classes or target range, self loops, isolated nodes). |
| start_sweepA | Create a sweep (an HPO study / grid search) that groups trial runs. Pass its sweep_id to log_run for each trial; the map shows the sweep as one collapsible fan with the best trial highlighted. Use run_sweep instead to have mltree launch a grid itself. |
| finish_sweepB | Mark a sweep finished and return its summary (trial counts and the best trial). |
| run_stepA | Execute a step's script as a subprocess and record it as a run automatically. Params are passed as CLI flags when the script uses argparse/click (or positionally for sys.argv scripts, or
key=value for hydra), and always as $MLTREE_PARAMS (JSON). Records params, script snapshot, command, exit status,
duration, log (.mltree/runs//log.txt) and metrics from |
| run_sweepB | Run a grid search: one sweep run plus one child run per combination, executed one after another. |
| run_logA | Return the status and the last lines of a run's log (live while it runs). |
| cancel_runB | Stop a run (SIGTERM, then SIGKILL after 5 s) or a whole sweep started from this session. |
| list_runsB | List runs, newest first. |
| best_runB | Find the best succeeded run by a metric. |
| open_mapA | Return the URL of the mltree map viewer (and start it if needed). Give the URL to the user. |
| scan_projectA | Build the map of an EXISTING project by static analysis (ast only; user code is never executed). Detects data reads/writes, argparse/click params, local imports, docstrings and step kinds, links steps whose output paths match other steps' inputs (falling back to file numbering and imports), and imports existing results as runs tagged 'imported'. Idempotent: re-scans update scanner-owned fields, add new steps, never delete, and keep edits made with add_step. Review the returned summary and fix it with connect_steps / add_step. |
| export_mapA | Write a single self-contained HTML file of the map (steps, code, runs, experiment tree, compare). It opens offline in any browser, read-only, with no server, so the user can email it, post it in Slack or host it on GitHub Pages / a gist. Returns the file path and size. It contains the scripts unless include_scripts=false: tell the user that before they share it. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| pipeline | The current mltree pipeline (nodes, edges, latest run status) as JSON |
TDQS
Scored across 21 tools
Most tools target a distinct resource+action: steps (add_step, connect_steps, scan_project), runs (log_run, run_step, list_runs, best_run, run_log, cancel_run), sweeps (start_sweep, finish_sweep, run_sweep), and outputs (get_pipeline, open_map, export_map). The closest overlaps are start_sweep vs run_sweep (explicitly cross-referenced in the descriptions) and add_step vs scan_project (manual upsert vs static analysis), both of which are clarified in text. gnn_summary is a narrowly scoped inspection tool that stands clearly apart.
Nearly all names are snake_case verb_noun (add_step, connect_steps, list_runs, log_run, compare_runs, run_step, cancel_run, export_map). A few deviate from that pattern—best_run (adjective_noun), data_status (noun_noun) and gnn_summary (noun_verb)—but they remain readable and unambiguous. No mixing of camelCase or inconsistent delimiters.
At 21 tools the surface sits in the heavy band, spread across pipeline modeling, run logging/execution, sweeps, data versioning, notes/tags, and three output mechanisms (viewer, pipeline read, HTML export). Each tool maps to a recognizable capability, so nothing is obviously redundant, but the set is larger than the core job strictly requires.
Lifecycle coverage is broad (init_project, scan_project, add/connect steps, run/log/compare/tag/note, sweeps, export), but there is no way to delete a step, run, or note, and no tool to remove or edit an edge once created with connect_steps. Those omissions are notable in a mutable graph store, since mistakes require editing underlying files by hand. Agents can work around gaps but cannot fully clean up the model.