Skip to main content
Glama
Sign In
MCP-Airflow-API

MCP-Airflow-API

by call518
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

list_task_instances_batch

Lists task instances in batches with optional state and start-date filters, enabling paginated Airflow task monitoring and targeted troubleshooting.

Instructions

[Tool Role]: Lists task instances in batch with date and state filtering.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_task_instances_batch"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoMaximum number of records to request per page. Default: 100.
stateNoOptional list of task states, such as ["failed", "running"]. Default: None.
offsetNoNumber of records to skip for pagination. Default: 0.
start_date_gteNoOptional inclusive task start time lower bound, in ISO 8601 format. Default: None.
start_date_lteNoOptional inclusive task start time upper bound, in ISO 8601 format. Default: None.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv3.7.4
    • addedInput schema / properties / limit / description
      Added value: +"Maximum number of records to request per page. Default:\n100."
    • addedInput schema / properties / offset / description
      Added value: +"Number of records to skip for pagination. Default: 0."
    • addedInput schema / properties / start_date_gte / description
      Added value: +"Optional inclusive task start time lower bound,\nin ISO 8601 format. Default: None."
    • addedInput schema / properties / start_date_lte / description
      Added value: +"Optional inclusive task start time upper bound,\nin ISO 8601 format. Default: None."
    • addedInput schema / properties / state / description
      Added value: +"Optional list of task states, such as [\"failed\",\n\"running\"]. Default: None."
  2. Addedv3.7.2
  3. Removedv3.6.5
  4. Changed6 schema fields changedv3.6.6
    • addedInput schema / additionalProperties
      Added value: +false
    • removedInput schema / properties / limit / title
      Removed value: -"Limit"
    • removedInput schema / properties / offset / title
      Removed value: -"Offset"
    • 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"
  5. Changed20 schema fields changedv1.0.0
    • removedInput schema / properties / dag_ids
      Removed value: -{
-  "default": null,
-  "items": {
-    "type": "string"
-  },
-  "title": "Dag Ids",
-  "type": "array"
-}
    • removedInput schema / properties / dag_run_ids
      Removed value: -{
-  "default": null,
-  "items": {
-    "type": "string"
-  },
-  "title": "Dag Run Ids",
-  "type": "array"
-}
    • removedInput schema / properties / duration_gte
      Removed value: -{
-  "default": null,
-  "title": "Duration Gte",
-  "type": "number"
-}
    • removedInput schema / properties / duration_lte
      Removed value: -{
-  "default": null,
-  "title": "Duration Lte",
-  "type": "number"
-}
    • removedInput schema / properties / end_date_gte
      Removed value: -{
-  "default": null,
-  "title": "End Date Gte",
-  "type": "string"
-}
    • removedInput schema / properties / end_date_lte
      Removed value: -{
-  "default": null,
-  "title": "End Date Lte",
-  "type": "string"
-}
    • removedInput schema / properties / execution_date_gte
      Removed value: -{
-  "default": null,
-  "title": "Execution Date Gte",
-  "type": "string"
-}
    • removedInput schema / properties / execution_date_lte
      Removed value: -{
-  "default": null,
-  "title": "Execution Date Lte",
-  "type": "string"
-}
    • addedInput schema / properties / limit
      Added value: +{
+  "default": 100,
+  "title": "Limit",
+  "type": "integer"
+}
    • addedInput schema / properties / offset
      Added value: +{
+  "default": 0,
+  "title": "Offset",
+  "type": "integer"
+}
    • removedInput schema / properties / pool
      Removed value: -{
-  "default": null,
-  "items": {
-    "type": "string"
-  },
-  "title": "Pool",
-  "type": "array"
-}
    • removedInput schema / properties / queue
      Removed value: -{
-  "default": null,
-  "items": {
-    "type": "string"
-  },
-  "title": "Queue",
-  "type": "array"
-}
    • 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 / items
      Removed value: -{
-  "type": "string"
-}
    • removedInput schema / properties / state / type
      Removed value: -"array"
    • removedInput schema / properties / task_ids
      Removed value: -{
-  "default": null,
-  "items": {
-    "type": "string"
-  },
-  "title": "Task Ids",
-  "type": "array"
-}
  6. First observed

TDQS

C2.9/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full disclosure burden, and it states nothing about permissions, read-only nature, default ordering, or result limits beyond what the schema already documents. For a list tool with zero annotation coverage this is thin, though the low risk of a read operation softens the gap.

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?

One sentence, front-loaded with the verb and resource, with no filler. The '[Tool Role]:' prefix is boilerplate that earns no place, which keeps it from a perfect score.

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, and the flat five-parameter schema is fully documented. However, with no annotations and no sibling differentiation, the agent lacks enough to confidently choose this over list_task_instances_all.

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

Parameters3/5

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

Schema description coverage is 100% and all five parameters are documented in-schema, so baseline is 3. The description names date and state filtering but adds no semantics beyond what the schema already says, such as how states are matched or the pagination interaction.

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 names a specific verb and resource ('Lists task instances') and adds the batch nature plus the supported filters (date and state). It is clear what the tool does, but it does not differentiate from the sibling list_task_instances_all, leaving ambiguity about when 'batch' matters.

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 explicit when-to-use guidance and no mention of alternatives, even though list_task_instances_all is an obvious sibling. The filters hint at valid use cases but the agent must infer the routing decision itself.

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

Deploy Server

Other Tools