MCP Zenml

MCP Server for ZenML

This project implements a Model Context Protocol (MCP) server for interacting with the ZenML API.

What is MCP?

The Model Context Protocol (MCP) is an open protocol that standardizes how applications provide context to Large Language Models (LLMs). It acts like a "USB-C port for AI applications" - providing a standardized way to connect AI models to different data sources and tools.

MCP follows a client-server architecture where:

• MCP Hosts: Programs like Claude Desktop or IDEs that want to access data through MCP
• MCP Clients: Protocol clients that maintain 1:1 connections with servers
• MCP Servers: Lightweight programs that expose specific capabilities through the standardized protocol
• Local Data Sources: Your computer's files, databases, and services that MCP servers can securely access
• Remote Services: External systems available over the internet that MCP servers can connect to

What is ZenML?

ZenML is an open-source platform for building and managing ML and AI pipelines. It provides a unified interface for managing data, models, and experiments.

For more information, see the ZenML website and our documentation.

Features

The server provides MCP tools to access core read functionality from the ZenML server, providing a way to get live information about:

Core Entities

• Users - user accounts and permissions
• Stacks - infrastructure configurations
• Stack Components - individual stack building blocks
• Flavors - available component types
• Service Connectors - cloud authentication

Pipeline Execution

• Pipelines - pipeline definitions
• Pipeline Runs - execution history and status
• Pipeline Steps - individual step details, code, and logs
• Schedules - automated run schedules
• Artifacts - metadata about data artifacts (not the data itself)

Deployment & Serving

• Snapshots - frozen pipeline configurations (the "what to run/serve" artifact)
• Deployments - runtime serving instances with status, URL, and logs
• Services - model serving endpoints

Organization & Discovery

• Projects - organizational containers for ZenML resources
• Tags - cross-cutting metadata labels for discovery
• Builds - pipeline build artifacts with image and code info

Models

• Models - ML model registry entries
• Model Versions - versioned model artifacts

Compatibility APIs (migration recommended)

• Pipeline run templates remain available in ZenML 0.97.0, while Snapshots are preferred for new workflows (see Migration Guide)

The server also allows you to trigger new pipeline runs using snapshots (preferred) or the deprecated template-based trigger parameter.

*Note: We're continuously improving this integration based on user feedback. Please join our Slack community to share your experience and help us make it even better!*

Tool profiles and write policy

The default compact profile advertises 16 tools. Seven generic tools cover the resource catalog, reads, ordinary mutations, and finite lifecycle actions:

Nine focused tools remain because they provide diagnostics, active context, streamed logs or code, pipeline execution, or an interactive App:

• diagnose_zenml_setup
• get_active_user and get_active_project
• trigger_pipeline
• get_step_logs, get_step_code, and get_deployment_logs
• open_pipeline_run_dashboard and open_run_activity_chart

get_step_logs returns at most 50,000 entries, oldest first, with a possibly_truncated flag, plus a note saying which entries are missing and why. Pass tail to get only the newest entries. On ZenML 0.97+ servers it pages through the log store; on 0.96 it uses the older single-request endpoint.

Use ZENML_MCP_PROFILE=legacy when an existing client still depends on the old entity-specific names such as list_pipeline_runs. This retains the characterized tool-name and schema compatibility layer for ZenML 0.97.0. It does not add support for older ZenML server versions. Use it only while migrating: legacy response shapes may expose more operational metadata than the compact tools, although the server omits credential-bearing configuration and other sensitive fields from both profiles.

Registration and write access are independent:

Set ZENML_MCP_WRITE_POLICY=read_only to remove all four generic mutation tools and trigger_pipeline from MCP discovery and dispatch. Resource discovery also omits create, update, delete, and action schemas. The older ZENML_MCP_READ_ONLY=true setting remains accepted; invalid policy values fail closed to read-only mode. An invalid ZENML_MCP_PROFILE stops startup with a configuration error.

Version 2.0.0 requires MCP Python SDK 2.2.0 and ZenML 0.96.4. The compact profile is the new default and is a breaking discovery change for clients that call entity-specific tool names. Set ZENML_MCP_PROFILE=legacy while migrating those clients, then move each call to the generic resource tools.

Mutation results distinguish completed, accepted, and unknown outcomes. The server does not retry a mutation after it may have reached ZenML. For an accepted or unknown result, follow the reconciliation instructions in the response before deciding whether to call again. Use the named read when one is available. Webhook creation and secret rotation can return a new signing secret once; later reads omit it. Delete schemas state whether an operation archives metadata, removes metadata, deprovisions a live resource, or can delete stored artifact data.

The first 2.0 release covers ordinary operations for projects, stacks and components, flavors, services, pipelines and runs, snapshots and templates, deployments, artifacts and versions, models and versions, tags, connectors, code repositories, webhooks, triggers, wait conditions, and hook invocations. Users, schedules, service connector types, secrets, and resource requests have the read-only coverage shown by zenml_describe_resources. It excludes ZenML Cloud control-plane administration, Resource Manager administration, user and credential administration, secret-value CRUD, connector login and verification, raw webhook events, and aggregate debugging or lineage tools.

Start a generic workflow by discovering the precise schema, then calling it:

zenml_describe_resources(resource_type="pipeline_run", operation="list")

zenml_list_resources( resource_type="pipeline_run", filters={"status": "completed", "sort_by": "desc:created"}, page=1, size=10, )

Prompts and resources remain available in both profiles. The analysis prompts, the bounded resource-schema endpoints, and most_recent_runs are MCP prompts or resources rather than tools.

Run-template compatibility

ZenML 0.97.0 retains run-template CRUD APIs. Snapshots are preferred for new workflows. Pipeline convenience creation and the template-based trigger parameter are deprecated. In the legacy profile, get_run_template and list_run_templates remain available for existing clients.

The legacy tag input remains in list_run_templates for schema compatibility, but ZenML 0.97.0 has no equivalent server-side filter. A non-null value is rejected before the SDK call. Snapshot tag filtering remains available.

Migration: Run Templates → Snapshots

Why the change? Snapshots replaced run templates as ZenML's preferred runnable pipeline artifact. The 0.97.0 SDK still supports run-template CRUD, while new code should use snapshots.

Quick Migration Guide

Example Workflow (Snapshot-First)

1. Discover project context:

→ get_active_project()

1. Find runnable snapshots: → zenml_list_resources(resource_type="snapshot", filters={"runnable": true, "named_only": true})

1. Trigger a run: → trigger_pipeline(snapshot_name_or_id="my-snapshot")

1. Check deployments: → zenml_list_resources(resource_type="deployment", filters={"status": "running"}) → get_deployment_logs(name_id_or_prefix="my-deployment", tail=100)

To override parameters when triggering a runnable snapshot, pass a ZenML run configuration (the snapshot itself remains unchanged):

trigger_pipeline(

snapshot_name_or_id="my-snapshot", run_configuration={ "steps": {"train": {"parameters": {"learning_rate": 0.01}}}, "enable_cache": False, }, )

For static snapshots, override step parameters as shown above. Top-level run_configuration={"parameters": {...}} overrides pipeline function parameters and is supported only for dynamic snapshots; ZenML rejects it for static snapshots.

Note: get_deployment_logs returns bounded output (default 100 lines, max 1000, capped at 100KB) and requires the appropriate deployer integration to be installed.

Quick Setup via Dashboard (Recommended)

The easiest way to set up the ZenML MCP Server is through your ZenML dashboard's MCP Settings page.

Navigate to Settings → MCP in your ZenML dashboard to get:

• Pre-configured snippets for your specific server URL and credentials
• One-click installation via deep links for supported IDEs
• Copy-paste configurations for VS Code, Claude Desktop, Cursor, Claude Code, OpenAI Codex, and more
• Docker and uv options based on your preference

ZenML Pro Users

The MCP Settings page lets you generate a Personal Access Token (PAT) with a single click. The token is automatically included in all generated configuration snippets.

ZenML OSS Users

1. First create a service account token via Settings → Service Accounts
2. Paste the token into the MCP Settings page
3. Copy the generated configuration for your IDE

Prefer manual setup? See the detailed instructions below.

MCP Apps (Experimental)

What are MCP Apps? MCP Apps are interactive HTML UIs that MCP servers can

serve directly into AI clients. They render in sandboxed iframes and can call

server tools bidirectionally. See the official announcement

for full details.

This server includes two experimental MCP Apps:

| Pipeline Runs Dashboard | open_pipeline_run_dashboard