Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
MLTREE_PROJECTNoPath 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_DIRNoProject 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

CapabilityDetails
tools
{
  "listChanged": false
}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}

Tools

Functions exposed to the LLM to take actions

NameDescription
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 MLTREE_METRIC name=value stdout lines or a JSON file written to $MLTREE_METRICS_FILE / a declared metrics*.json output. Returns the run and the end of its log.

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

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription
pipelineThe current mltree pipeline (nodes, edges, latest run status) as JSON

TDQS

A3.5/5.0

Scored across 21 tools

Disambiguation4/5

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.

Naming Consistency4/5

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.

Tool Count3/5

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.

Completeness3/5

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.

Maintenance

ActivityMaintained
ResponsivenessNo issues