The surface follows the REST API closely, so what you can do is exactly what your Airflow account can do, and the destructive calls sit next to the reads with nothing in between. clear_task_instances and clear_dag_run both take dry_run, which is the difference between a plan and an action at three in the morning. Queued dataset events get their own reads and deletes at both levels, which matters only if you schedule on datasets rather than on cron.
A server over the Airflow REST API, 68 tools covering DAGs, DAG runs, task instances, XComs, datasets, connections, variables, pools and the instance's own health.
- DAGs fetched by ID pattern or tag, paused and unpaused one at a time or in bulk, their source read, and their files re-parsed after an edit
- DAG runs triggered with a logical date and a note, listed by state or date window, cleared, deleted, or moved to a state by hand
- Task instances cleared with a dry run first, states set across upstream, downstream, past and future selections, and each try listed and read separately
- Connections created, updated and tested before anything depends on them, with variables and pools as first-class objects alongside
- Dataset events read and created by URI, and queued dataset events inspected or dropped at both the DAG and the dataset level
- Instance introspection: health, version, loaded plugins and providers, import errors, and the event log filtered by DAG, task, owner or event type
- XCom entries listed and fetched, deserialised or returned as strings
AIRFLOW_HOST pointing at an Airflow deployment reachable from wherever the server runs, plus AIRFLOW_USERNAME and AIRFLOW_PASSWORD for an account whose role permits the calls you intend — delete_dag and delete_dag_run sit in the same tool list as the reads.
One command plus a key — npx -y @smithery/cli install @yangkyeongmo/mcp-server-apache-airflow --client claude, then supply credentials