get_dagsLABSCO SUMMARY
The failed-DAG loop, without the web UI.
Find the DAG, find the run that failed, read the task log that explains it, then clear the run so it retries. In the Airflow UI that is four screens; here it is four calls in the window where you were already asking the question.
What it is
A Python MCP server for Apache Airflow 3, talking to REST API v2. Its tools list DAGs and their tasks, trigger and clear runs, pause and unpause a DAG, and read run history, task instances, logs and import errors.
What you get
- All DAGs listed with filters, and the tasks inside one of them
- A DAG run triggered, with optional run configuration
- A failed DAG run cleared so it retries
- A DAG paused or unpaused by setting its state
- Run history, task instances and aggregate statistics for a DAG
- The execution log for a task instance
- The DAG import and parsing errors Airflow is currently reporting
Requirements
A reachable Airflow 3 instance and a .env holding airflow_baseurl and airflow_api_url. Authentication prefers a JWT in airflow_jwt_token — get one by posting your username and password to /auth/token on your Airflow URL — and falls back to airflow_username and airflow_password. Python dependencies come from requirements.txt.
Setup effort
Build from source — git clone https://github.com/chayasin/mcp-airflow-simple
USE CASES
Finding out why last night's pipeline failed
Walk from the DAG to its recent runs to the task instance that failed, then read that task's log.
Retrying a run that failed halfway
Clear the run so Airflow schedules it again, then watch the run list for the new attempt.
Kicking off an ad-hoc or backfill run
Trigger the DAG with the configuration the run needs, rather than editing a schedule.
Working out why a DAG never showed up
Import and parsing errors are the usual answer, and they have their own call.
Taking a noisy DAG out of the schedule
Pause it by setting its state, and unpause it the same way when the fix is in.
Getting a feel for how a DAG has been behaving
Aggregate run statistics and the task list, before you start reading individual runs.
14 tools
Listed in project docs. Your client may show a different list.
get_dag_taskstrigger_dag_runclear_dag_runset_dag_stateget_dag_runsget_task_instancesget_dag_statsget_task_logsget_import_errorsget_connectionsget_connectiontest_connectioncheck_healthBEFORE YOU INSTALL
What to know first
Tools you get
14 tools named in the project's documentation.
Requires
- Python 3.8+
- Apache Airflow 3.x with the REST API enabled, reachable from this machine
Where it runs
Both documented setups run the server on your machine.
INSTALLATION
Connect your client
You clone this one yourself.
Server setup
git clone https://github.com/chayasin/mcp-airflow-simple
cd mcp-airflow-simple
cp .env.example .env
pip install -r requirements.txtWith Airflow running, get a token (use your own Airflow URL, username and password):
curl -X POST "http://localhost:8080/auth/token" -H "Content-Type: application/json" -d '{"username":"airflow","password":"airflow"}'Put the returned token in .env as airflow_jwt_token, with airflow_baseurl and airflow_api_url set to your Airflow (airflow_username and airflow_password are the fallback)
MCP Clients
Claude Desktop — Windows
{
"mcpServers": {
"airflow": {
"command": "python",
"args": [
"c:\\<YOUR_FOLDER>\\mcp-airflow-simple\\server.py"
],
"env": {
"airflow_api_url": "http://localhost:8080/api/v2",
"airflow_jwt_token": "<YOUR_AIRFLOW_JWT_TOKEN>"
}
}
}
}c:\<YOUR_FOLDER> is the folder you cloned into, and <YOUR_AIRFLOW_JWT_TOKEN> is the token from the /auth/token call.
Claude Desktop — macOS, Linux
{
"mcpServers": {
"airflow": {
"command": "python3",
"args": [
"<YOUR_FOLDER>/mcp-airflow-simple/server.py"
],
"env": {
"airflow_api_url": "http://localhost:8080/api/v2",
"airflow_jwt_token": "<YOUR_AIRFLOW_JWT_TOKEN>"
}
}
}
}<YOUR_FOLDER> is the folder you cloned into, and <YOUR_AIRFLOW_JWT_TOKEN> is the token from the /auth/token call.