start_schedule

MCP tool from Dagster MCP by fabdendev

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

How to use it

start_schedule is exposed by the Dagster MCP MCP server. Add the server to your MCP client (Claude Desktop, Cursor, Windsurf and others), and the start_schedule tool becomes available to the model automatically. See the full listing for setup details and every tool this server provides.

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_sensor

Start (enable) a sensor so it resumes evaluating

stop_schedule

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

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