# Incident Response MCP for Apache Airflow [Health: Active]

**Category:** 📊 Data Platforms  
**Repository:** https://github.com/madamak/apache-airflow-mcp-server  
**GitHub Stars:** 2  
**Views:** 0  
**Installs:** 0  
**Upvotes:** 0  
**Directory Page:** https://allmcps.com/mcp/incident-response-mcp-for-apache-airflow

## Description
Diagnose Airflow failures from UI links with bounded logs and optional recovery actions.

## Tools
Capabilities this server exposes over MCP:

- **airflow_list_instances** — List configured instance keys and the default
- **airflow_describe_instance** — Host, API version, auth type (secrets redacted)
- **airflow_resolve_url** — Parse an Airflow UI URL into instance + dag/run/task identifiers
- **airflow_list_dags** — DAGs with pause state and UI links
- **airflow_get_dag** — DAG details
- **airflow_list_dag_runs** — Runs with state filters and ordering (latest first by default)
- **airflow_get_dag_run** — Single run details
- **airflow_list_task_instances** — Task attempts for a run; filter by `state` / `task_ids` server-side
- **airflow_get_task_instance** — Task metadata, retries, timings, optional rendered template fields
- **airflow_get_task_instance_logs** — Logs with level filtering, tailing, context lines, and byte caps
- **airflow_dataset_events** — Dataset (Airflow 2) / asset (Airflow 3) events
- **airflow_trigger_dag** — Trigger a run with optional conf/logical date/note
- **airflow_clear_task_instances** — Clear task instances across runs (`dry_run=true` by default)
- **airflow_clear_dag_run** — Clear a whole run (`dry_run=true` by default)
- **airflow_pause_dag** — Toggle DAG scheduling

## Claude Desktop Quick Installation
Install path detected from listing signals. Uses `uvx` (confidence: high):

```json
"mcpServers": {
  "incident-response-mcp-for-apache-airflow": {
    "command": "uvx",
    "args": ["--from","apache-airflow-mcp-server","--with","apache-airflow-client==3.3.0","airflow-mcp"],
    "env": {
      "AIRFLOW_MCP_HOST": "",
      "AIRFLOW_MCP_USERNAME": "",
      "AIRFLOW_MCP_PASSWORD": "",
      "AIRFLOW_MCP_API_VERSION": "",
      "AIRFLOW_MCP_READ_ONLY": "",
      "AIRFLOW_MCP_TOKEN_REFRESH_SECONDS": ""
    }
  }
}
```

**Requires environment variables:** `AIRFLOW_MCP_HOST`, `AIRFLOW_MCP_USERNAME`, `AIRFLOW_MCP_PASSWORD`, `AIRFLOW_MCP_API_VERSION`, `AIRFLOW_MCP_READ_ONLY`, `AIRFLOW_MCP_TOKEN_REFRESH_SECONDS` — the values above are empty placeholders; fill in real credentials before running (see the repository for what each one is for).

## Documentation

## What Incident Response MCP for Apache Airflow does

Incident Response MCP for Apache Airflow MCP server exposes Apache Airflow operations as MCP tools for clients such as Claude, Cursor, and VS Code. Its workflow is centered on investigating failed DAG runs: provide an Airflow UI URL, resolve its instance and identifiers, inspect the related run and task attempts, and retrieve bounded log output.

The server supports multiple configured Airflow instances when they use the same API family. Instance descriptions include the host, API version, and authentication type, while secrets are redacted from responses and operation logs. Responses also include a request ID that can be matched with structured server logs.

## How it works

The server communicates with Airflow through the generated `apache-airflow-client`. Airflow 2 uses the v1 API client, while Airflow 3 uses the v2 client. The installed client version should match the deployed Airflow version, particularly for Airflow 3, where generated models may change within a major release.

An agent can resolve an Airflow UI link into an instance, DAG, run, and task reference. It can then list or retrieve DAG runs and task instances, filter task instances by state or task ID, and inspect retries, timings, metadata, and optionally rendered template fields. Log retrieval supports level filtering, tailing, context lines, byte limits, and truncation metadata to keep responses bounded.

The Incident Response MCP for Apache Airflow MCP server also applies an SSRF guard that rejects unknown hosts. Airflow 3 deployments can use bearer JWTs; basic credentials are exchanged for a JWT and refreshed periodically.

## Setup and configuration

Install the package with `uv tool install` or run it through `uvx`, adding an Airflow client version that matches the target deployment. Configure a single instance with environment variables, or use the server's multi-instance configuration described by the project. The server can run over stdio or HTTP; the HTTP example listens locally and exposes `/mcp`, with `/health` available for a health check.

Relevant environment variables include:

- `AIRFLOW_MCP_HOST` for the Airflow base URL.
- `AIRFLOW_MCP_USERNAME` and `AIRFLOW_MCP_PASSWORD` for basic credentials.
- `AIRFLOW_MCP_API_VERSION` to select `v1` or `v2` explicitly.
- `AIRFLOW_MCP_READ_ONLY=true` to omit write tools.
- `AIRFLOW_MCP_TOKEN_REFRESH_SECONDS` to control JWT refresh timing.

For Airflow 2.11, the documented client is `apache-airflow-client==2.10.0`. For Airflow 3.3, the documented client is `apache-airflow-client==3.3.0`.

## Tools and capabilities

The tool set includes instance discovery and description, UI URL parsing, DAG listing and retrieval, DAG-run listing and retrieval, task-instance inspection, and dataset or asset event queries. Task logs can be narrowed before they reach the MCP response.

Recovery and scheduling operations include triggering a DAG with optional configuration, logical date, or note; clearing selected task instances; clearing an entire DAG run; and toggling DAG pause state. Clear operations default to `dry_run=true`. Write tools carry destructive-operation annotations that MCP clients can use when requesting confirmation.

## Limitations and notes

A single server process loads only one generated client major, so all configured instances must use the same API family. Run separate processes for Airflow 2 and Airflow 3. Airflow 3.0 through 3.2 and Airflow 2.5 through 2.10 are not in the current live compatibility matrix.

For Airflow 3, token refresh does not automatically re-authenticate after a 401 response. The refresh interval should remain below the deployment's JWT expiry. API-specific fields and options can differ; unsupported Airflow 3 clear options are rejected rather than silently narrowed. The project is an independent community project and is not affiliated with or endorsed by the Apache Software Foundation.

_Full upstream README: https://allmcps.com/mcp/incident-response-mcp-for-apache-airflow/readme_