MCP-Airflow-API

Overview Schema Source Related Servers Discussions Admin

list_task_instances_all

List task instances with filters for DAG, run, task, dates, duration, state, and pool to monitor and troubleshoot Airflow workflows.

Instructions

[Tool Role]: Lists task instances with comprehensive filtering options.

Args: dag_id: Exact DAG identifier, as returned by list_dags; not its display name. Default: None. dag_run_id: Exact DAG run identifier for the selected DAG. Default: None. task_id: Exact task identifier within the selected DAG. Default: None. execution_date_gte: Optional inclusive task execution time lower bound, in ISO 8601 format. Default: None. execution_date_lte: Optional inclusive task execution time upper bound, in ISO 8601 format. Default: None. start_date_gte: Optional inclusive task start time lower bound, in ISO 8601 format. Default: None. start_date_lte: Optional inclusive task start time upper bound, in ISO 8601 format. Default: None. end_date_gte: Optional inclusive task end time lower bound, in ISO 8601 format. Default: None. end_date_lte: Optional inclusive task end time upper bound, in ISO 8601 format. Default: None. duration_gte: Optional minimum task duration in seconds. Default: None. duration_lte: Optional maximum task duration in seconds. Default: None. state: Optional list of task states, such as ["failed", "running"]. Default: None. pool: Optional list of Airflow pool names to filter task instances. Default: None. limit: Maximum number of records to request per page. Default: 100. offset: Number of records to skip for pagination. Default: 0.

Input Schema

Name	Required	Description	Default
`pool`	No
`limit`	No
`state`	No
`dag_id`	No
`offset`	No
`task_id`	No
`dag_run_id`	No
`duration_gte`	No
`duration_lte`	No
`end_date_gte`	No
`end_date_lte`	No
`start_date_gte`	No
`start_date_lte`	No
`execution_date_gte`	No
`execution_date_lte`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Addedv3.7.2Oct 24, 2026
Removedv3.6.5Apr 30, 2026
Changed16 schema fields changedv3.6.6Apr 30, 2026
- addedInput schema / additionalProperties
```
Added value: +false
```
- removedInput schema / properties / dag_id / title
```
Removed value: -"Dag Id"
```
- removedInput schema / properties / dag_run_id / title
```
Removed value: -"Dag Run Id"
```
- removedInput schema / properties / duration_gte / title
```
Removed value: -"Duration Gte"
```
- removedInput schema / properties / duration_lte / title
```
Removed value: -"Duration Lte"
```
- removedInput schema / properties / end_date_gte / title
```
Removed value: -"End Date Gte"
```
- removedInput schema / properties / end_date_lte / title
```
Removed value: -"End Date Lte"
```
- removedInput schema / properties / execution_date_gte / title
```
Removed value: -"Execution Date Gte"
```
- removedInput schema / properties / execution_date_lte / title
```
Removed value: -"Execution Date Lte"
```
- removedInput schema / properties / limit / title
```
Removed value: -"Limit"
```
- removedInput schema / properties / offset / title
```
Removed value: -"Offset"
```
- removedInput schema / properties / pool / title
```
Removed value: -"Pool"
```
- removedInput schema / properties / start_date_gte / title
```
Removed value: -"Start Date Gte"
```
- removedInput schema / properties / start_date_lte / title
```
Removed value: -"Start Date Lte"
```
- removedInput schema / properties / state / title
```
Removed value: -"State"
```
- removedInput schema / properties / task_id / title
```
Removed value: -"Task Id"
```

Changed27 schema fields changedv1.0.0Jan 3, 2026

addedInput schema / properties / dag_id / anyOf

Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

removedInput schema / properties / dag_id / type
```
Removed value: -"string"
```

addedInput schema / properties / dag_run_id / anyOf

Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

removedInput schema / properties / dag_run_id / type
```
Removed value: -"string"
```

addedInput schema / properties / duration_gte / anyOf

Added value: +[
+  {
+    "type": "number"
+  },
+  {
+    "type": "null"
+  }
+]

removedInput schema / properties / duration_gte / type
```
Removed value: -"number"
```

addedInput schema / properties / duration_lte / anyOf

Added value: +[
+  {
+    "type": "number"
+  },
+  {
+    "type": "null"
+  }
+]

removedInput schema / properties / duration_lte / type
```
Removed value: -"number"
```

addedInput schema / properties / end_date_gte / anyOf

Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

removedInput schema / properties / end_date_gte / type
```
Removed value: -"string"
```

addedInput schema / properties / end_date_lte / anyOf

Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

removedInput schema / properties / end_date_lte / type
```
Removed value: -"string"
```

addedInput schema / properties / execution_date_gte / anyOf

Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

removedInput schema / properties / execution_date_gte / type
```
Removed value: -"string"
```

addedInput schema / properties / execution_date_lte / anyOf

Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

removedInput schema / properties / execution_date_lte / type
```
Removed value: -"string"
```
changedInput schema / properties / limit / default
```
Previous value: -20New value: +100
```

addedInput schema / properties / pool / anyOf

Added value: +[
+  {
+    "items": {
+      "type": "string"
+    },
+    "type": "array"
+  },
+  {
+    "type": "null"
+  }
+]

removedInput schema / properties / pool / type
```
Removed value: -"string"
```

removedInput schema / properties / queue

Removed value: -{
-  "default": null,
-  "title": "Queue",
-  "type": "string"
-}

addedInput schema / properties / start_date_gte / anyOf

Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

removedInput schema / properties / start_date_gte / type
```
Removed value: -"string"
```

addedInput schema / properties / start_date_lte / anyOf

Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

removedInput schema / properties / start_date_lte / type
```
Removed value: -"string"
```

addedInput schema / properties / state / anyOf

Added value: +[
+  {
+    "items": {
+      "type": "string"
+    },
+    "type": "array"
+  },
+  {
+    "type": "null"
+  }
+]

removedInput schema / properties / state / type
```
Removed value: -"string"
```

addedInput schema / properties / task_id

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Task Id"
+}

First observedAug 18, 2025

TDQS

B3.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full behavioral burden but only restates parameter mechanics. It does not explicitly state that the operation is read-only, does not describe permissions or rate limits, and gives no behavioral context about pagination beyond the limit/offset defaults (e.g., ordering, total counts, or whether results span all DAGs by default).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The Args block is long but appropriate for 15 parameters, and the role statement is front-loaded before the parameter detail. Each entry is brief and earns its place; the '[Tool Role]:' prefix is slightly awkward but not harmful.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained. But for a 15-parameter tool with zero annotations and zero schema descriptions, the description omits sibling differentiation and behavioral traits like read-only status and pagination behavior. It is minimally adequate but leaves meaningful gaps about when to choose this over list_task_instances_batch.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate, and it largely does: it explains that dag_id is the exact identifier 'as returned by list_dags; not its display name', that date bounds are inclusive ISO 8601, and that durations are in seconds. It does not document relationships between parameters (e.g., whether dag_run_id requires dag_id) or enumerate valid state values beyond an example, but the coverage is strong for 15 undocumented parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource ('Lists task instances') and notes comprehensive filtering, which is enough for an agent to know what it does. However, it never distinguishes this tool from the sibling 'list_task_instances_batch' or explains what 'all' means relative to that alternative.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance, no exclusions, and no mention of alternatives such as list_task_instances_batch or get_task_instance_details. The phrase 'comprehensive filtering options' is the only hint about appropriate context, leaving selection between siblings entirely to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server