How do I use dagster-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@dagster-mcp check instance status and re-run failed jobs" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

dagster-mcp

by fabdendev

Overview Schema Related Servers Score Discussions

Python

Remote

Dagster MCP

PyPI version Downloads License: MIT Python 3.12+ Tests

An MCP server that gives AI agents full visibility and control over your Dagster instance — like an SRE for your data pipelines.

Works with any MCP client: Claude Code, Claude Desktop, Cursor, and more.

Why this exists

Data pipelines break at 3 AM. Schedules silently stop firing. Assets go stale. Instead of waking up to a dashboard full of red, give your AI agent the tools to monitor, diagnose, and fix your Dagster instance autonomously.

Agent: Checking instance health...
       get_instance_status() -> healthy: false, daemon "SCHEDULER" unhealthy

Agent: Scheduler daemon is down. Let me check recent failures...
       get_runs(statuses=["FAILURE"], limit=5) -> 3 failed runs in the last hour

Agent: Diagnosing the most recent failure...
       get_run_failure_summary("run_abc123") ->
         failed_steps: ["transform_orders"]
         root_cause: "NullPointerError: column 'price' is null"
         suggestions: ["Single step failed — consider re-running from failure"]

Agent: Re-launching the failed job...
       launch_job("etl_pipeline", "my_project") -> run_id: "run_def456", status: STARTED

Related MCP server: ensemble-mcp

What it does

19 tools across 6 categories, designed for autonomous DataOps workflows:

Category	Tools	What an agent can do
Runs	`get_runs` `get_run_status` `get_run_logs` `get_run_stats` `get_run_failure_summary`	Find failures, diagnose root causes, inspect logs and step timing
Assets	`search_assets` `get_asset_details` `get_recent_materializations` `get_asset_health`	Discover assets, check freshness, detect stale data
Jobs	`list_jobs`	Inventory all jobs across code locations
Schedules & Sensors	`list_schedules` `list_sensors` `get_tick_history`	Detect silent failures, missed ticks, sensor errors
Instance	`get_instance_status` `list_code_locations` `list_backfills`	Global health check, daemon status, code location errors
Actions	`launch_job` `launch_job_with_partitions` `terminate_run` `reload_code_location`	Re-run failed jobs, backfill partitions, stop stuck runs, reload after deploy

Actions are opt-in: set DAGSTER_READ_ONLY=false to enable write operations.

Quick start

Prerequisites

Python 3.12+
uv (recommended) or pip
A running Dagster instance (self-hosted or Cloud)

Install

The package is published on PyPI.

Option A — run directly with uvx (no install needed):

uvx dagster-mcp

Option B — install with pip:

pip install dagster-mcp

Option C — clone and run:

git clone https://github.com/fabdendev/dagster-mcp.git
cd dagster-mcp
uv sync

Configure

Single environment

Variable	Description	Default
`DAGSTER_URL`	Base URL of your Dagster instance	`http://localhost:3000`
`DAGSTER_API_TOKEN`	Dagster Cloud API token (leave empty for self-hosted)	(empty)
`DAGSTER_EXTRA_HEADERS`	JSON object of additional request headers sent to Dagster GraphQL	(empty)
`DAGSTER_READ_ONLY`	When `true`, only read tools are exposed (no launch/terminate/reload)	`true`

Self-hosted:

export DAGSTER_URL=http://localhost:3000

Dagster Cloud:

export DAGSTER_URL=https://myorg.dagster.cloud/prod
export DAGSTER_API_TOKEN=your-dagster-cloud-user-token

Custom auth / proxy headers:

export DAGSTER_EXTRA_HEADERS='{"Authorization":"Bearer your-token","X-My-Header":"value"}'

Multiple environments

Use DAGSTER_ENVS to configure several Dagster instances in one server. Every tool then accepts an optional env parameter so the LLM can target the right instance.

Variable	Description	Default
`DAGSTER_ENVS`	JSON object mapping env names to `{url, token?, extra_headers?}` configs	(empty)
`DAGSTER_DEFAULT_ENV`	Env name to use when `env` is not passed to a tool	(empty)

export DAGSTER_ENVS='{
  "prod": {"url": "https://myorg.dagster.cloud/prod", "token": "prod-token"},
  "staging": {"url": "https://myorg.dagster.cloud/staging", "token": "stg-token"},
  "dev": {"url": "http://localhost:3000"}
}'
export DAGSTER_DEFAULT_ENV=prod

When DAGSTER_ENVS is set, DAGSTER_URL / DAGSTER_API_TOKEN / DAGSTER_EXTRA_HEADERS are ignored. If only one env is defined, it is used automatically even without DAGSTER_DEFAULT_ENV.

Add to your MCP client

Add to ~/.claude/settings.json:

Single env:

{
  "mcpServers": {
    "dagster": {
      "command": "uvx",
      "args": ["dagster-mcp"],
      "env": {
        "DAGSTER_URL": "http://localhost:3000"
      }
    }
  }
}

Multiple envs:

{
  "mcpServers": {
    "dagster": {
      "command": "uvx",
      "args": ["dagster-mcp"],
      "env": {
        "DAGSTER_ENVS": "{\"prod\":{\"url\":\"https://myorg.dagster.cloud/prod\",\"token\":\"prod-token\"},\"dev\":{\"url\":\"http://localhost:3000\"}}",
        "DAGSTER_DEFAULT_ENV": "prod"
      }
    }
  }
}

Add to claude_desktop_config.json:

{
  "mcpServers": {
    "dagster": {
      "command": "uvx",
      "args": ["dagster-mcp"],
      "env": {
        "DAGSTER_URL": "http://localhost:3000"
      }
    }
  }
}

{
  "mcpServers": {
    "dagster": {
      "command": "uv",
      "args": ["run", "--directory", "/path/to/dagster-mcp", "dagster-mcp"],
      "env": {
        "DAGSTER_URL": "http://localhost:3000"
      }
    }
  }
}

Tool reference

Runs

Tool	Description
`get_runs`	List recent runs, filter by job name and/or status
`get_run_status`	Get status, config, tags, and run lineage (re-execution chain via rootRunId/parentRunId)
`get_run_logs`	Get structured log events with pagination and optional level filtering (`ERROR`, `WARNING`, `INFO`)
`get_run_stats`	Get per-step execution stats: timing, materializations, expectation results
`get_run_failure_summary`	Consolidated failure diagnosis — failed steps, root cause error, step durations, and suggestions in one call

Assets

Tool	Description
`search_assets`	Discover assets by key prefix or group name
`get_asset_details`	Get description, upstream/downstream dependencies, partitions, latest materialization
`get_recent_materializations`	Get materialization history with metadata for an asset
`get_asset_health`	Consolidated health view — staleness, freshness policy, last run status (works with single asset or entire group)

Jobs, Schedules & Sensors

Tool	Description
`list_jobs`	List all jobs across all code locations (use to find names for `launch_job`)
`list_schedules`	List schedules with status (RUNNING/STOPPED), cron, target job, next tick
`list_sensors`	List sensors with status and target jobs
`get_tick_history`	Tick-by-tick history for a schedule or sensor — essential for detecting silent failures

Instance & Code Locations

Tool	Description
`get_instance_status`	Start here — global health: daemon status, queued run count, code location errors
`list_code_locations`	List all code locations and their load status
`list_backfills`	List recent backfills with status and partition progress

Write Operations

Tool	Description
`launch_job`	Launch a job or materialize specific assets (supports tags and asset selection)
`launch_job_with_partitions`	Launch a partitioned job for one or more partition keys; creates a backfill (supports `from_failure` to retry only failed steps)
`terminate_run`	Stop a stuck or runaway run
`reload_code_location`	Reload a code location after deploy

Write tools require DAGSTER_READ_ONLY=false (default is true).

How it differs from the official Dagster MCP

	dagster-mcp (this project)	dg[mcp] (official)
Purpose	Monitor and operate a running instance	Write Dagster code and scaffold components
When	Operations time	Development time
What it does	Inspect runs, read logs, check assets, launch jobs	Generate definitions, use `dg` CLI, build pipelines

They serve different purposes and work well together.

Compatibility

Tested with Dagster 1.6+. The RunsFilter field name (jobName vs pipelineName) is auto-detected via schema introspection, so the server works across all Dagster versions without configuration.

Development

uv sync --extra dev
uv run ruff check dagster_mcp/    # lint
uv run pytest                     # tests (98 tests)
uv run python -m dagster_mcp      # start server locally

License

MIT

This server cannot be installed

license - permissive license

quality - not tested

maintenance

How are these scores calculated?

Maintenance

–Maintainers

–Response time

2dRelease cycle

3Releases (12mo)

Commit activity

Issues opened vs closed

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Latest Blog Posts

Lightport: Open-Sourcing Glama's AI Gateway
By punkpeye on April 27, 2026.
open source
OpenAI
Tool Definition Quality Score (TDQS)
By punkpeye on April 3, 2026.
mcp
The Hackers Who Tracked My Sleep Cycle
By punkpeye on March 26, 2026.
security

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/fabdendev/dagster-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server