Allows interaction with Apache Airflow REST API, providing tools to list DAGs, get DAG runs, trigger runs, check task instances, and monitor scheduler health.
MCP server that exposes Apache Airflow REST API operations as tools. Built with FastMCP.
# Run directly with uvx (no install needed)
uvx mcp-airflow
# Or install with pip
pip install mcp-airflowFor development:
uv pip install -e ".[dev]"
# or with dependency groups
uv sync --group devRelated MCP server: astro-airflow-mcp
Set these environment variables (or create a .env file from .env.example):
Variable | Description | Example |
| Airflow REST API base URL. Use |
|
| Auth username (JWT on 3.x, basic auth on 2.x) |
|
| Auth password |
The client picks the auth scheme automatically based on your Airflow version:
Airflow 3.x (JWT) — a JWT token is obtained from the /auth/token endpoint
using AIRFLOW_USERNAME/AIRFLOW_PASSWORD, sent as a Bearer token, and
refreshed automatically. Point AIRFLOW_BASE_URL at /api/v2.
Airflow 2.x (basic auth) — if the JWT flow is unavailable, the client falls
back to HTTP basic auth with the same username/password. Point AIRFLOW_BASE_URL
at /api/v1.
Run the server:
mcp-airflowOr add to your MCP client config (e.g., Claude Desktop):
{
"mcpServers": {
"airflow": {
"command": "mcp-airflow",
"env": {
"AIRFLOW_BASE_URL": "http://100.x.x.x:8080/api/v2",
"AIRFLOW_USERNAME": "admin",
"AIRFLOW_PASSWORD": "your-password"
}
}
}
}Tool | Description |
| List all DAGs with paused/active status |
| Get all DAG runs from today with status |
| Get the latest run status for a specific DAG |
| Trigger a manual DAG run |
| Get task instances for a specific DAG run |
| Check for failed DAGs in the last 24 hours |
| Check scheduler heartbeat and metadatabase status |
pytestMIT
Check for failed DAG runs in the last 24 hours.
Returns a list of DAGs that had at least one failed run in the past 24 hours, with execution dates.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool checks the last 24 hours and returns failed runs with dates. However, it does not mention side effects (though likely read-only), authorization requirements, rate limits, or potential errors. The core behavior is clear but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no redundant information. It is efficiently structured, front-loading the purpose and then providing detail on the return value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the return value (list of DAGs with execution dates), which is sufficient given the tool's simplicity. It does not detail the output schema format, but the context notes an output schema exists. For a check tool with no parameters, the description is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema coverage is 100%. No additional parameter information is needed. Baseline for zero parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks for failed DAG runs in the last 24 hours and returns a list with execution dates. It uses specific verbs ('check', 'returns') and identifies the resource ('failed DAG runs'). The purpose is distinct from sibling tools like 'list_dags' or 'check_scheduler_health'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when monitoring recent failures, but does not explicitly specify when to avoid this tool or mention alternatives. It provides clear context for use but lacks exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the Airflow scheduler health via the /health endpoint.
Returns the scheduler status and latest heartbeat timestamp.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates a read-only operation (health check) and specifies return values. No annotations were provided, so description carries full burden; it is clear but could explicitly state no side effects or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. Front-loaded with verb 'Check' and resource 'scheduler health'. Efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameterless health check tool with an output schema, the description covers purpose and return values adequately. No gaps for this complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, and schema coverage is 100%. Baseline for 0 params is 4, and description adds no unnecessary param info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks Airflow scheduler health via a specific endpoint and lists the return values (status and heartbeat timestamp). It is distinct from sibling tools that focus on DAGs and tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance. It is implied that this is for scheduler health checks, but no alternatives are discussed or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the latest run status for a specific DAG.
Args:
dag_id: The DAG identifier.
Returns the state, execution date, and duration of the most recent run.
| Name | Required | Description | Default |
|---|---|---|---|
| dag_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description discloses that the tool returns state, execution date, and duration, which is beyond the input schema. This provides behavioral transparency for a simple read operation. No annotations to contradict.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with a clear purpose statement followed by parameter and return information. Every sentence adds value. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one parameter, the description covers purpose, parameter, and return values. It lacks error handling context and usage guidelines, but given the simplicity it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter dag_id is described as 'The DAG identifier.' This adds explanation beyond the schema's type and title. However, it lacks specifics like format, examples, or validation rules. With 0% schema coverage, the description provides minimal compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets the latest run status for a specific DAG. It is distinct from siblings like get_dag_runs_today which gets multiple runs, but does not explicitly contrast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines provided. The description does not indicate when to use this tool over alternatives like check_failed_dags or get_dag_runs_today. An agent would need to infer from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all DAG runs from today with their status.
Returns every DAG run that started on the current UTC date, grouped by status (success, failed, running, queued).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden. It reveals that the tool returns runs from the current UTC date grouped by status, which is useful. However, it does not mention whether it's read-only, rate limits, or error handling, but the grouping detail adds value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the action and then adding detail. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, the presence of an output schema, and sibling context, the description sufficiently covers what the tool does, including the output grouping. It feels complete for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so baseline is 4. The description correctly mentions no required inputs and adds no parameter information, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get', the resource 'all DAG runs from today', and the grouping by status, distinguishing it from sibling tools like get_dag_run_status (specific run) or check_failed_dags (failure-focused).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies the use case: retrieving today's DAG runs grouped by status. It does not explicitly state when not to use it or list alternatives, but the sibling tool list provides context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get individual task instances for a specific DAG run.
Args:
dag_id: The DAG identifier.
run_id: The DAG run identifier.
Returns the list of tasks with their state, duration, and operator.
| Name | Required | Description | Default |
|---|---|---|---|
| dag_id | Yes | ||
| run_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the burden of disclosing behavior. It states the return format (list with state, duration, operator) but does not mention side effects, auth requirements, or error scenarios. The safety profile (read-only) is implied but not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: one sentence for purpose, followed by parameter definitions and return statement. It is front-loaded and contains no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (though not shown), the description covers the essential return details. It lacks mention of pagination or error handling, but for a simple retrieval tool with few parameters, it is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides no descriptions (0% coverage), so the description fully compensates by defining dag_id as 'The DAG identifier' and run_id as 'The DAG run identifier.' These are brief but add meaning beyond the schema's type-only definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves individual task instances for a specific DAG run, which is a distinct function from siblings like get_dag_run_status or get_dag_runs_today. It uses a specific verb ('Get') and resource ('task instances').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention when it is appropriate to retrieve task instances compared to other DAG-related queries, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all DAGs with their paused/active status.
Returns a summary of every DAG registered in Airflow, including
the dag_id, whether it is paused, and whether it is active.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It states the tool returns a summary with specific fields (dag_id, paused, active), which is transparent. However, it lacks any mention of side effects, pagination, or other behavioral nuances beyond the immediate output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two short sentences, no fluff, and front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and an output schema (mentioned in context), the description fully explains what is returned and the scope of the tool. No missing information for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and schema coverage is 100%. The description confirms the tool lists all DAGs without filtering, which adequately conveys the parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'list all DAGs with their paused/active status', which is a specific verb and resource. This distinguishes it from siblings like 'check_failed_dags' or 'get_dag_run_status' which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (to get a summary of all DAGs). While it does not explicitly contrast with alternatives, the tool's simple nature and sibling names make usage intuitive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Trigger a manual DAG run.
Args:
dag_id: The DAG identifier to trigger.
Returns confirmation with the new run ID and state.
| Name | Required | Description | Default |
|---|---|---|---|
| dag_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It mentions triggering and returning confirmation (run ID, state), but omits critical details such as idempotency, permission requirements, potential side effects (e.g., overwriting scheduled runs), or error conditions. For a mutation tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences plus a brief Args/Returns section. Every word adds value, and the purpose is front-loaded. The structure is clean and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no nested objects) and existence of an output schema (implied by 'Returns confirmation'), the description covers the core action. However, it lacks integration with sibling tools (e.g., suggesting get_dag_run_status to monitor the triggered run) and fails to mention prerequisites or errors, making it just adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates by explaining dag_id as 'The DAG identifier to trigger.' This adds meaningful context beyond the schema's title and type. For a single parameter, this is adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Trigger' and the resource 'manual DAG run', making the tool's purpose unambiguous. It differentiates from sibling tools like check_failed_dags or list_dags by explicitly indicating a write/action operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: to trigger a manual DAG run. However, it provides no guidance on when not to use it or alternatives (e.g., if a DAG is already running). This is a minor gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every tool targets a distinct aspect of Airflow (failed DAGs, scheduler health, specific DAG run status, today's runs, task instances, DAG listing, manual trigger). No two tools overlap in purpose.
All tool names follow a consistent verb_noun pattern with lowercase and underscores (e.g., check_failed_dags, get_dag_run_status). No deviations or mixed conventions.
7 tools is well-scoped for an Airflow monitoring/management server. It covers essential operations without being excessive or minimal.
Covers core monitoring (health, DAG run status, task instances) and triggering. Missing pause/unpause, DAG details, or run deletion, but these are secondary for typical agent workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server that lets AI assistants use all OneSchema features exposed via the public API.
MCP Hub: AI service discovery, per-user OAuth, and multi-service workflow orchestration
MCP server for secureFlows: token-free URL builders and integration-linting tools for AI agents.
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/antonio-mello-ai/mcp-airflow'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
