MCP-Airflow-API

Overview Schema Source Related Servers Discussions Admin

get_dags_detailed_batch

Retrieve detailed information and latest run status for multiple Airflow DAGs in a single batch request, with pagination plus ID, name, active, and paused filters.

Instructions

[Tool Role]: Retrieves detailed information for multiple DAGs in batch with latest run information.

Args: limit: Maximum number of records to request per page. Default: 100. offset: Number of records to skip for pagination. Default: 0. fetch_all: Fetch every DAG page; ignores limit and offset when True. Default: False. id_contains: Optional substring to match against DAG identifiers. Default: None. name_contains: Optional substring to match against DAG display names. Default: None. is_active: Optional active-status filter; None includes both statuses. Default: None. is_paused: Optional paused-status filter; None includes both statuses. Default: None.

Input Schema

Name	Required	Description	Default
`limit`	No
`offset`	No
`fetch_all`	No
`is_active`	No
`is_paused`	No
`id_contains`	No
`name_contains`	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
Changed8 schema fields changedv3.6.6Apr 30, 2026
- addedInput schema / additionalProperties
```
Added value: +false
```
- removedInput schema / properties / fetch_all / title
```
Removed value: -"Fetch All"
```
- removedInput schema / properties / id_contains / title
```
Removed value: -"Id Contains"
```
- removedInput schema / properties / is_active / title
```
Removed value: -"Is Active"
```
- removedInput schema / properties / is_paused / title
```
Removed value: -"Is Paused"
```
- removedInput schema / properties / limit / title
```
Removed value: -"Limit"
```
- removedInput schema / properties / name_contains / title
```
Removed value: -"Name Contains"
```
- removedInput schema / properties / offset / title
```
Removed value: -"Offset"
```
First observedAug 18, 2025

TDQS

A3.5/5.0

Behavior3/5

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 does disclose useful behavior: `fetch_all` overrides limit/offset, and `None` on the status filters means no filtering. It does not state what 'detailed' actually contains beyond 'latest run information', nor does it note that there is no way to name specific DAG ids, only substring filters.

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

Conciseness3/5

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

The tool role is front-loaded in one clear sentence before the argument list, which is good structure. However, the Args block repeats every default already declared in the schema ('Default: 100', 'Default: 0'), which is wasted text given the schema is machine-visible.

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

Completeness4/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 all seven parameters are covered. The main remaining gap is positioning relative to the closely related `list_dags` and `get_dag` siblings, which an agent would need in order to choose correctly.

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%, yet the description documents all seven parameters with defaults and meaning, including the non-obvious point that `is_active=None` includes both statuses. This compensates well for the bare schema. A small deduction for not clarifying substring matching semantics (case sensitivity, anchoring).

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 opens with a specific verb and resource: retrieve detailed information for multiple DAGs in batch, including latest run information. That is much clearer than the name alone. However, it never distinguishes this from the sibling tools `list_dags` or `get_dag`, so an agent still has to infer which of the three to reach for.

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

Usage Guidelines3/5

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

The word 'batch' combined with the pagination and filter arguments implies this is the bulk-fetch option, so usage can be inferred. Yet the description never states when to prefer this over `list_dags` (lighter) or `get_dag` (single DAG), and it gives no exclusions or prerequisites.

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

Deploy Server