stop_schedule

MCP tool from Dagster MCP by fabdendev

Stop (disable) a schedule — persists across restarts; does not terminate in-flight runs

How to use it

Project documentation lists stop_schedule for the Dagster MCP MCP server. Add the server to your MCP client (Claude Desktop, Cursor, Windsurf and others), then check which tools your installed version makes available. Tool availability can depend on configuration and credentials. A server handshake does not verify this tool’s behavior. See the full listing for setup details.

Install Dagster MCP

$uvx dagster-mcp

FULL DAGSTER MCP LISTING

Other tools in Dagster MCP (26)

backfill_assets

Launch a partition backfill by asset selection with optional run config; respects each asset's BackfillPolicy server-side

get_asset_details

Get description, upstream/downstream dependencies, partitions, latest materialization

get_asset_health

Consolidated health view — staleness, freshness policy, last run status (works with single asset or entire group)

get_instance_status

Start here — global health: daemon status, queued run count, code location errors

get_recent_materializations

Get materialization history with metadata for an asset

get_run_failure_summary

Consolidated failure diagnosis — failed steps, root cause error, step durations, and suggestions in one call

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_status

Get status, config, tags, and run lineage (re-execution chain via rootRunId/parentRunId)

get_runs

List recent runs, filter by job name and/or status

get_tick_history

Tick-by-tick history for a schedule or sensor — essential for detecting silent failures. Accepts optional repositoryname / locationname to disambiguate a name shared by several code locations

launch_job

Launch a named job; assetkeys 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 fromfailure to retry only failed steps)

list_backfills

List recent backfills with status and partition progress

list_code_locations

List all code locations and their load status

list_jobs

List jobs across code locations, optionally filtered by exact repositoryname and/or locationname (use to find names for launchjob)

list_schedules

List schedules with status (RUNNING/STOPPED), cron, target job, next tick

list_sensors

List sensors with status and target jobs

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

reload_code_location

Reload a code location after deploy

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

search_assets

Discover assets by key prefix or group name

start_schedule

Start (enable) a schedule so it launches runs on its cron

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 gettickhistory

terminate_run

Stop a stuck or runaway run