What can you do with this server?

This server provides an MCP interface to monitor, diagnose, and autonomously manage a Dagster data orchestration instance, with read-only tools always available and write operations that can be enabled. * Monitoring & Diagnostics * Runs: List runs, get detailed status/logs/stats, and consolidated failure summaries with root-cause analysis. * Assets: Search/discover assets, resolve complex selections, inspect details and materialization history, and assess asset health (freshness, staleness). * Jobs: List all jobs across code locations. * Schedules & Sensors: List schedules/sensors with status, and review tick history to detect silent failures. * Instance Health: Check daemon status, queued runs, code location errors, list code locations, and monitor backfills. * Autonomous Actions (write operations, opt-in) * Materialize assets or launch backfills for partition ranges. * Launch jobs (including with partitions, retries from failure). * Start/stop schedules and sensors. * Terminate stuck or runaway runs. * Reload code locations after deployments.

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.

Dagster officially develops and supports their own Dagster Plus MCP server. See the documentation here.

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

Agent: One sensor keeps firing on bad data. Checking its ticks...
       get_tick_history("orders_sensor", "SENSOR") -> 12 consecutive FAILURE ticks

Agent: Stopping it until the upstream fix lands...
       stop_sensor("orders_sensor") -> status: STOPPED

Related MCP server: ensemble-mcp

What it does

27 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` `resolve_asset_selection` `get_asset_details` `get_recent_materializations` `get_asset_health`	Discover assets, preview lineage selections, 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	`materialize_assets` `backfill_assets` `launch_job` `launch_job_with_partitions` `terminate_run` `start_schedule` `stop_schedule` `start_sensor` `stop_sensor` `reload_code_location`	Materialize concrete assets with config, backfill partitions, launch jobs, stop stuck runs, start or stop schedules and sensors, 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, no schedule or sensor start/stop)	`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`); EngineEvent events include `metadataEntries`
`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
`resolve_asset_selection`	Resolve key/group/tag/kind/owner predicates, wildcards, boolean logic, roots/sinks, and lineage traversal into concrete asset keys without launching anything
`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)

Two-step asset workflow

Start by resolving and reviewing a selection expression:

resolve_asset_selection(
  asset_selection="group:analytics and (kind:dbt or key:*benchmark)"
)

→ {
    "asset_keys": [
      "warehouse/analytics/orders",
      "warehouse/analytics/reranker_benchmark"
    ],
    "assets": [...]
  }

For concrete, unpartitioned assets, pass the returned keys to materialize_assets with any required launch config and tags:

materialize_assets(
  asset_keys=[
    "warehouse/analytics/orders",
    "warehouse/analytics/reranker_benchmark"
  ],
  run_config={"ops": {"benchmark": {"config": {"limit": 1000}}}},
  tags={"triggered_by": "agent"}
)

For partitioned assets, pass the same resolved keys to backfill_assets instead:

backfill_assets(
  asset_keys=["warehouse/analytics/daily_orders"],
  partition_start="2026-07-01",
  partition_end="2026-07-07",
  run_config={"resources": {"warehouse": {"config": {"pool": "benchmark"}}}}
)

resolve_asset_selection is available in both read-only and read-write modes. It returns external, observable, non-executable, and partitioned matches so the caller can inspect the complete result. The write tools re-fetch current asset definitions before execution. resolve_asset_selection and materialize_assets require Dagster 1.9+.

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. Accepts optional `repository_name` / `location_name` to disambiguate a name shared by several code locations

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
`materialize_assets`	Launch concrete, unpartitioned asset keys with run config and tags; infers one compatible repository/job, includes compatible checks, and expands required non-subsettable multi-asset neighbors
`backfill_assets`	Launch a partition backfill by asset selection with optional run config; respects each asset's `BackfillPolicy` server-side
`launch_job`	Launch a named job; `asset_keys` remains supported for compatibility and is sent through GraphQL `assetSelection`, but the two-step asset workflow is preferred
`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)
`start_schedule`	Start (enable) a schedule so it launches runs on its cron
`stop_schedule`	Stop (disable) a schedule — persists across restarts; does not terminate in-flight runs
`start_sensor`	Start (enable) a sensor so it resumes evaluating
`stop_sensor`	Stop (disable) a sensor — the fix for a runaway or erroring sensor found via `get_tick_history`

Schedule/sensor names are unique only within a repository. If the same name exists in several code locations, the start/stop tools refuse to act and list the candidates; pass repository_name / location_name to disambiguate. Successful calls echo the resolved repository and location. | 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 Dagster's official AI tooling

Dagster builds and supports its own AI tooling. If you are a Dagster+ customer, start with theirs — it is first-party, needs no local runtime, and reaches Dagster+ platform objects (alerting, Issues, Insights) that this project cannot. This project exists mainly for people running open-source / self-hosted Dagster, which the official server's documented setup does not cover.

Everything in the "official" column comes from Dagster's own docs at https://docs.dagster.io/guides/labs/dagster-mcp (retrieved 2026-07-30), or from Dagster directly in #21. Dagster's docs nowhere state that open-source or self-hosted Dagster is unsupported; what they document is a Dagster-hosted URL, a required Dagster-Cloud-Organization header, and a Dagster+ user token. Their capability matrix is a snapshot of today and Dagster expects to keep adding to it, so treat the gaps below as current rather than permanent.

	dagster-mcp (this project)	Dagster+ MCP server (official)	`dagster-expert` skill (official)
What it is	MCP server you run yourself (Python, MIT)	Dagster-hosted remote MCP endpoint at `https://mcp.agent.dagster.cloud/mcp`	An Agent Skill — markdown instructions loaded by your coding agent, not an MCP server
When you use it	Operations time, against a live instance	Operations time, against a Dagster+ deployment	Development time, against your local codebase
Works with self-hosted / OSS Dagster	Yes — points at any Dagster webserver (`DAGSTER_URL`, default `http://localhost:3000`; `/graphql` is appended). No token required	Not per the documented setup: the only URL given is Dagster-hosted, and connecting requires a `Dagster-Cloud-Organization` header plus a Dagster+ user token	Yes — Apache-2.0 markdown files you copy locally
Works with Dagster+	Yes — sends a `Dagster-Cloud-Api-Token` header; extra headers via `DAGSTER_EXTRA_HEADERS`	Yes — this is its only documented target	n/a
Setup	Local process launched by your MCP client (Python 3.12+, e.g. `uvx dagster-mcp`), configured with env vars	No local runtime: `claude mcp add --transport http dagster-plus https://mcp.agent.dagster.cloud/mcp --header "Dagster-Cloud-Organization: …" --header "Authorization: Bearer …"`	Copy the skill files into your agent
Maturity	v0.8.0 on PyPI (pre-1.0), MIT, single maintainer with occasional outside contributions, "AS IS, WITHOUT WARRANTY OF ANY KIND", no SLA	Labelled by Dagster as Preview: "under active development, and not considered ready for production use… the APIs may change", and published under `/guides/labs/`	Current, no preview label
Runs	View, launch, terminate, per-step stats, log retrieval, consolidated failure summary	View ✅, Create/Launch ✅, Delete/Terminate ✅, Insights metrics ✅, Update ❌ (Dagster's matrix); run logs View ✅	n/a
Assets	View, search, health, resolve selection syntax, and materialize specific assets (`resolve_asset_selection` → `materialize_assets`, with run config and partition ranges)	View ✅ and Insights metrics ✅; Create/Launch, Update and Delete marked ❌ — i.e. no asset-level materialization tool, though launching a run is supported	n/a
Schedules & sensors	List, tick history, start/stop	Not supported today — confirmed by Dagster, who expect to add it	n/a
Backfills & partitions	List backfills, launch partitioned jobs, backfill assets over a partition range	Not listed in Dagster's capability matrix	n/a
Code locations & instance health	List/reload code locations, instance status, daemon heartbeats, queued-run counts	Deployments View ✅ and Insights ✅; code locations and daemon health not listed (Dagster+ manages the daemon)	n/a
Alerting, Insights, Dagster+ Issues	Not supported — no alerting, cost/Insights metrics, or Issues equivalent	Alert policies and Dagster+ Issues: View / Create / Update / Delete all ✅. Insights metrics ✅ on Runs, Assets and Deployments. All three are documented Dagster+ features (Issues is in limited early access)	n/a
Multiple instances	Yes — `DAGSTER_ENVS` maps names to arbitrary URLs and tokens, with a per-tool `env` argument; you can mix OSS and Dagster+	Deployments within one Dagster+ organization, selected per tool call	n/a
Write safety	17 read tools always registered; the 10 write tools are registered only when `DAGSTER_READ_ONLY=false` (default `true`), so clients cannot even see them otherwise. This is a convenience guardrail, not a security boundary: it is a process-level env var read at import, and the API token you configure keeps whatever rights it has	Enforced server-side by Dagster+ token permissions. The docs default to a personal user token; a service user is offered as the alternative for scoped, non-human auth (service users are a Dagster+ Pro feature)	n/a
Support	Best-effort, community, GitHub issues; no SECURITY.md or documented disclosure process	First-party vendor	First-party vendor

Use the official Dagster+ MCP server if you are on Dagster+ and want alerting, Issues or Insights/cost analysis from an agent, want no local runtime, or need vendor support and a supplier your procurement process will accept.

Use this project if you run open-source or self-hosted Dagster, or you need asset-level materialization, schedule/sensor control, backfills, or code-location and daemon operations from an agent.

For Dagster+ users the two are complementary rather than competing — nothing stops you running both. This project is not affiliated with or endorsed by Dagster Labs.

Compatibility

The monitoring and existing action tools are tested with Dagster 1.6+. resolve_asset_selection and materialize_assets require Dagster 1.9+ and verify the required GraphQL capabilities before querying or launching. The RunsFilter field name (jobName vs pipelineName) is auto-detected via schema introspection. Configured asset backfills also feature-detect LaunchBackfillParams.runConfigData and return a clear compatibility error when an older schema does not expose it. Schedule and sensor start/stop work on Dagster 1.6+: the stop mutations are sent with the originId/selectorId argument pair sourced from InstigationState.id/selectorId, which modern Dagster re-parses as a compound id and older versions accept directly, so no version branch is needed. The mutations select error messages via the ... on Error interface fragment rather than per-type fragments, because ScheduleNotFoundError only joined ScheduleMutationResult in Dagster 1.9 and spreading it on 1.6-1.8 would fail document validation.

Development

uv sync --extra dev
uv run ruff check dagster_mcp/    # lint
uv run pytest                     # run the test suite
uv run python -m dagster_mcp      # start server locally

License

MIT

Install Server

license - permissive license

quality

maintenance

How are these scores calculated?

Maintenance

–Maintainers

29dResponse time

3wRelease cycle

7Releases (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.

Tools

View all tools

Related MCP Servers

AIOps MCP
Observability Agent Orchestration Autonomous Agents
Elvisaryan
A
license
-
quality
B
maintenance
A multi-agent MCP server that turns LLMs into an autonomous incident-response copilot, enabling rapid investigation, correlation, and remediation of production incidents.
Last updated 2026-05-18
MIT
ensemble-mcp
Knowledge & Memory Agent Orchestration Developer Tools
LynkByte
A
license
-
quality
D
maintenance
An MCP server providing intelligence infrastructure for AI agent pipelines, including vector memory, drift detection, model routing, skills discovery, session management, codebase indexing, and context compression, all running locally with zero LLM/API calls.
Last updated 2026-07-20
1
MIT
GitHub Actions MCP Server
CI/CD & DevOps Developer Tools Monitoring
muhammedehab35
A
license
A
quality
C
maintenance
An intelligent MCP server that gives AI agents full control over GitHub Actions CI/CD pipelines, including real-time monitoring, log analysis, AI-powered failure diagnosis, and deployment management.
Last updated 2026-06-19
13
569
1
ISC
mcp-kafka-observer
Observability Monitoring
Rushi264
A
license
-
quality
D
maintenance
An MCP server that gives AI agents real-time observability into Apache Kafka clusters, enabling natural language queries for broker health, consumer lag, and diagnostics.
Last updated 2026-03-12
MIT

View all related MCP servers

Related MCP Connectors

microservices.sh
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
mcp
MCP server connecting AI agents to non-custodial staking data across 130+ networks.
PlanWright
Control plane for autonomous software labor. Agents claim objectives over MCP with audit trail.

View all MCP Connectors

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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