The read surface is unusually careful about context: get_runs, query_runs and search_runs_by_tags each state in their own descriptions that runs are large and ask you to keep limits small. Promotion follows the MLflow 3 pattern through set_model_alias and copy_model_version, while transition_model_version_stage is marked deprecated since MLflow 2.9 and kept for stage-based deployments. The delete tools have no confirmation step, and delete_model_version and delete_registered_model both say the removal cannot be recovered — unlike delete_run and delete_experiment, which move to a lifecycle stage the MLflow API can still reach.
A client for an MLflow tracking server, 40 tools across experiments, runs, artifacts and the model registry.
- Experiment access — list them, search by filter string with a sort order, fetch one by name, and read the metric names, parameter names and tag keys used across its runs.
- Run queries at several levels: runs for an experiment, one run in full, a nested run's parent, MLflow filter-syntax queries, tag search, and the best run by a named metric.
- Metric detail — latest values for a run, the full history of a single metric, and a side-by-side comparison across runs.
- Artifacts: browse a run's artifact tree, download one to a local path, or read a text or JSON artifact's content directly.
- Registry reads — registered models, every version of one, a version by number or by alias, and the latest version per stage.
- Registry writes: register a model from a URI, assign aliases, tag models, runs and experiments, update a version description, copy a version into another model, and transition stages for legacy deployments.
- Deletion for aliases, model versions, registered models, runs and experiments, plus a health check on the tracking server.
An MLflow tracking server, addressed by MLFLOW_TRACKING_URI.
One command — uvx mlflow-mcp
