mltree-mcp

Overview Schema Source Related Servers Discussions Admin

log_run

Record a pipeline step execution with parameters, metrics, artifacts, parent run, and file versions so experiment runs stay traceable and data changes are detectable.

Instructions

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.

Input Schema

Name	Required	Description	Default
`step`	Yes	Name of the step that was executed
`tags`	No	Optional tags, e.g. ['hpo', 'gcn']
`notes`	No	Free-text notes about the run
`params`	No	Parameters actually used for this run
`status`	No	Run outcome	succeeded
`history`	No	Step-wise metrics for curves, e.g. [{'epoch': 1, 'train_loss': 0.9, 'val_rmse': 1.1}, ...]
`metrics`	No	Numeric results, e.g. {'val_rmse': 0.61, 'r2': 0.78}
`sweep_id`	No	Sweep this run is a trial of (from start_sweep)
`artifacts`	No	Files produced (paths relative to project), as a list or {name: path}; copied into .mltree/runs/<run_id>/ when <= 50 MB
`record_data`	No	Fingerprint the step's input/output files now (data versions). False for results from elsewhere
`parent_run_id`	No	Run this one branches from (e.g. the base config of an HPO trial)

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv0.8.0Oct 24, 2026

addedInput schema / properties / history

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "additionalProperties": {
+          "type": "number"
+        },
+        "type": "object"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Step-wise metrics for curves, e.g. [{'epoch': 1, 'train_loss': 0.9, 'val_rmse': 1.1}, ...]",
+  "title": "History"
+}

addedInput schema / properties / record_data

Added value: +{
+  "default": true,
+  "description": "Fingerprint the step's input/output files now (data versions). False for results from elsewhere",
+  "title": "Record Data",
+  "type": "boolean"
+}

addedInput schema / properties / sweep_id

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Sweep this run is a trial of (from start_sweep)",
+  "title": "Sweep Id"
+}

First observedv0.4.0Oct 23, 2026

TDQS

B3.3/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full behavioral burden. It adds useful context that SHA-256 versions of input/output files are recorded so later runs can detect data changes, but it does not state that this is a write/mutation operation, nor does it cover permissions, duplicate handling, or error behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the core action and followed by one sentence of useful behavioral context about data versioning. No filler and no repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained, and full schema coverage documents the parameters. But with 11 parameters and no annotations, the description should still clarify write semantics and distinguish this tool from run_step and run_log; those gaps keep it from being complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all 11 parameters are already documented in the schema. The description restates some of the same fields (params, metrics, artifacts, parent run) without adding syntax, format, or edge-case semantics beyond what the schema provides, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Record one execution of a step', and enumerates what is captured (params, metrics, artifacts, parent run). However, it gives no differentiation from similarly named siblings such as run_step, run_log, and list_runs, so an agent cannot tell from the description alone which tool to pick.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit when-to-use or when-not-to-use guidance, and no mention of alternatives like run_step or run_log. Usage is only weakly implied by 'Record one execution of a step', leaving the agent to infer routing from the name alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.