Apache Airflow MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.2
Disambiguation5/5
Each tool has a clearly distinct purpose, targeting specific Airflow entities (DAGs, runs, tasks, instances, datasets) and actions (list, get, clear, trigger, pause/unpause, describe, resolve). No two tools perform the same operation on the same entity, and descriptions make boundaries clear.
Naming Consistency5/5
All tools follow a consistent 'airflow_verb_noun' pattern (e.g., airflow_list_dags, airflow_trigger_dag). No mixing of conventions or unusual naming styles, making it easy for agents to predict tool names.
Tool Count4/5
With 16 tools, the count is slightly above the high end of 'well-scoped' (3-15), but it is reasonable given the complexity of Apache Airflow. The tools cover a comprehensive set of operations without feeling bloated or redundant.
Completeness4/5
The tool surface covers all core Airflow interactions: listing, getting, clearing, triggering, pausing/unpausing DAGs, runs, and task instances, plus logs, dataset events, and instance management. Minor gaps exist (e.g., no DAG update or deletion), but those are less common operations and the set still enables effective agent workflows.
Average 4.1/5 across 16 of 16 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 27 commits in the last 12 weeks
- Last stable release on July 16, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint. The description adds parameter coercion details (limit truncation) and return format, but does not disclose additional behavioral traits beyond annotations.
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 description is mostly concise with a clear heading and structured parameter and return sections. However, the parameter list is slightly verbose and could be more compact.
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?
Given the tool's simplicity and the presence of output schema in description, the description covers basic usage. However, the contradiction about required/optional dataset_uri and lack of error or pagination details reduce completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains each parameter, including limit's type coercion, but contradicts the schema by stating dataset_uri is required when schema marks it optional with default null. Schema coverage is 0%, so description had burden but the contradiction reduces clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List dataset events,' specifying the verb 'list' and the resource 'dataset events.' It distinguishes this tool from siblings which focus on DAGs, task instances, and instances.
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?
No guidance on when to use this tool versus alternatives. The description does not mention contextual prerequisites or exclusion criteria, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and idempotentHint=true, so the description is not required to disclose safety. The description adds that the tool returns a dictionary with 'dag_run', 'ui_url', and 'request_id', which is useful but not extensive behavioral context. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the main purpose, and uses a clear list for parameters. Every sentence adds value without redundancy. Well-structured for quick parsing.
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?
Given the presence of an output schema and annotations, the description covers the basic purpose, parameters, and return structure. However, it lacks clarification on required parameter combinations (all optional but not all combinations valid) and does not anchor usage relative to many sibling tools. Adequate but not fully complete.
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?
The input schema has 0% description coverage, so the description must compensate. It lists parameters with basic descriptions (e.g., 'DAG identifier', 'Instance key (optional)'), adding minimal meaning beyond the names. However, it does not explain how parameters interact or which combinations are required, leaving gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get a single DAG run and a UI link', specifying the verb (Get), resource (single DAG run), and an additional unique feature (UI link). It distinguishes from sibling tools like airflow_list_dag_runs and airflow_get_dag by focusing on a single run and including the link.
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?
The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites, required parameter combinations, or exclusions. The usage context is only implied by the tool's purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint and idempotentHint. The description adds useful behavioral context: return format (dictionary with fields) and error handling (ToolError with compact JSON payload), which goes beyond what annotations convey.
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?
Description is relatively concise but mixes sections (Parameters, Returns, Raises) without clear formatting. It could be more structured, but no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity (1 param, output schema exists, annotations cover safety), the description adequately covers input, output, and error behavior. No missing essential details.
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?
Only one parameter 'url' with schema coverage 0%. Description adds 'Airflow UI URL (http/https)', providing some meaning beyond the schema. Baseline adjusted due to low coverage, but description is minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Parse an Airflow UI URL, resolve instance and identifiers', using a specific verb and resource. It distinguishes from sibling tools like airflow_clear_dag_run or airflow_get_dag which perform different operations.
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?
No guidance on when to use this tool versus alternatives. The description does not mention any context, prerequisites, or exclusions that would help an agent decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description adds valuable behavioral details: pagination via limit/offset, parameter coercion, mutual exclusivity of instance and ui_url, error payload structure, and return schema. This goes beyond annotations.
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 description is well-structured with sections for parameters and returns. It is informative but slightly verbose; each sentence adds value. Could be marginally more concise.
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?
Given the output schema existence and rich annotations, the description covers return format and error handling. However, it does not explicitly clarify when to use this tool versus the many sibling tools (e.g., airflow_get_dag), leaving a minor gap in contextual completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates by explaining each parameter (defaults, accepted types, coercion rules, mutual exclusivity). This provides clear semantics that the schema alone does not convey.
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 clearly states the tool lists DAGs with pause state and UI link for a target instance. It distinguishes the basic listing function from sibling tools like airflow_get_dag (retrieves a single DAG) and airflow_list_dag_runs, but does not explicitly differentiate its scope.
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?
The description lacks guidance on when to use this tool versus alternatives. It does not specify that this is for obtaining an overview of all DAGs or compare to other listing tools. No explicit when-not-to-use or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, idempotent, non-destructive. Description adds significant behavioral details: default sorting, parameter coercion, dependency logic for instance/ui_url/dag_id, and error format. No contradictions with annotations.
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?
Well-structured with headings and bullet points. Slightly verbose but no redundant information. Each sentence adds value. Appropriate length for 8 parameters.
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?
Covers all parameters, default behavior, return format, and error handling. Given the presence of output schema in description and annotations, it is sufficiently complete. Could mention pagination or rate limits but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description fully compensates. Every parameter is explained with defaults, coercion, optionality, and dependencies (e.g., dag_id required if ui_url not provided). Adds meaning beyond schema (e.g., fractional truncation, order_by mapping).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it lists DAG runs with default ordering and includes UI URLs. It specifies the verb 'list' and resource 'DAG runs', and distinguishes from sibling tools like 'airflow_get_dag_run' (single run) and 'airflow_list_dags' (list DAGs).
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?
No explicit guidance on when to use this tool versus alternatives (e.g., get_dag_run, list_dags). It does not state conditions or prerequisites, leaving the agent to infer usage from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly and idempotent, so the description adds value by stating 'never secrets' and detailing the return structure. It does not contradict annotations and provides additional behavioral context (no secrets exposed, error format).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise (three short sections: purpose, parameter, returns). Every sentence adds value, and the structure is clear and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and explicit return and error specifications, the description is complete. The output schema is effectively described in text, and no additional context is needed.
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?
The only parameter 'instance' has no description in the schema (0% coverage). The description adds meaning by calling it an 'instance key' and providing an example ('data-stg'), which clarifies what the string represents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool 'describe a configured Airflow instance (host + metadata, never secrets)'. The verb 'describe' and resource 'Airflow instance' are specific, and the distinction from sibling tools (which deal with DAGs, runs, tasks) is clear.
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?
No guidance on when to use this tool versus alternatives. The description does not mention when not to use it, prerequisites, or how it differs from other describe/list tools (e.g., airflow_get_dag, airflow_list_instances).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true. The description adds the return format and error handling details. However, it does not disclose potential side effects (e.g., creating a run even if another is active) or authorization needs beyond what annotations imply.
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 description is well-structured with a lead sentence, a parameter list, and return/error details. It is slightly lengthy but each section adds value. Front-loading the main action is effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, mutual exclusivity, output schema exists), the description covers the essential information: how to specify the DAG and instance, what configuration and notes can be provided, and the expected returns and errors. No major gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/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 fully explain parameters. It provides clear descriptions for all 7 parameters, including mutual exclusivity between 'instance' and 'ui_url', the meaning of 'conf' as a dict or JSON string, and the optional nature of most fields. This adds significant value over the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Trigger a DAG run') and the resource ('DAG run with optional configuration'). Among sibling tools like 'airflow_get_dag_run', 'airflow_list_dags', etc., this uniquely describes a mutation that initiates a run, making the purpose distinct.
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 description implies usage for starting a new DAG run, but does not explicitly state when to use this tool versus alternatives like 'airflow_get_dag_run' (for retrieving an existing run) or other lifecycle tools. No exclusion criteria or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true (mutation). The description adds that it sets is_paused=False and returns a response dict, clarifying the state change. It also discloses error format (ToolError with JSON payload). This is good context beyond annotations, though it doesn't mention potential side effects like triggering downstream tasks.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise, with a one-line summary followed by a bulleted parameter list and return value info. Every sentence adds value without redundancy. Structure is clear and easy to scan.
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?
Given no output schema, the description adequately covers return values, error handling, and parameter relationships. It lacks details on permissions or when to prefer alternative tools, but for a three-parameter tool with annotations, it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates. It explains each parameter: instance (optional, mutually exclusive with ui_url), ui_url (optional, takes precedence), dag_id (required if ui_url not provided). This adds critical constraints and meaning beyond the schema's bare types and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it resumes DAG scheduling by setting is_paused=False, which distinguishes it from siblings like airflow_pause_dag (pauses) and airflow_trigger_dag (triggers a run). The verb 'resume' combined with the specific resource 'DAG scheduling' provides a precise action.
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?
The description does not provide explicit guidance on when to use this tool versus alternatives. It lacks statements about prerequisites, when not to use, or comparisons to related tools like airflow_pause_dag or airflow_trigger_dag. The parameter documentation partially implies resolution logic but no strategic usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate safe read, and description adds details on optional rendering, truncation, and sensor try_number behavior. No contradictions.
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?
Well-structured with summary, parameter list, return dict, and notes. Concise yet informative, though slightly lengthy.
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?
Covers parameter behavior and return structure adequately; output schema exists for full details. Leaves minor gaps (e.g., error cases), but overall complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema coverage at 0%, description explains all 7 parameters, including target selection, required identifiers, and max_rendered_bytes coercion. Provides full context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Return task metadata, config, attempt summary, optional rendered fields, and UI URLs.' It identifies the specific resource (task instance) and distinguishes from sibling list/other tools.
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?
Provides parameter guidance (URL precedence, required identifiers) and mentions the sibling tool for logs, but lacks explicit when-to-use vs. alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already mark destructiveHint=true, and the description reinforces this with a clear 'destructive' label. It explains the dry_run parameter (default true, must be set false to mutate) and the return/error formats. However, it does not mention authorization requirements or side effects beyond the dry_run flag.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a one-sentence intro, followed by parameter and return bullets. Every sentence adds value, with no redundant or vague statements.
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?
Given 14 parameters, no required ones, and an output schema, the description covers parameters and return value thoroughly. It lacks context on prerequisites (e.g., permissions) or edge cases, but for a complex tool it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by providing a detailed bullet list for all 14 parameters, including optionality, mutual exclusivity (instance vs ui_url), and the effect of dry_run. This adds significant meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Clear task instances') and the resource ('for a DAG across one or more runs'), with the note 'destructive' distinguishing it from read-only tools. Sibling tools like airflow_clear_dag_run are implicitly differentiated by the focus on task instances rather than entire runs.
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 description lists many parameters and the dry_run behavior but does not provide explicit guidance on when to use this tool versus alternatives like airflow_clear_dag_run or airflow_get_task_instance. The 'destructive' label and filter semantics imply use cases, but direct comparisons are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent. Description adds valuable details: auto-resolution of ui_url, return structure (dag, ui_url, request_id), and error format (compact JSON payload). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Highly concise with clear sections: purpose, parameter instructions, returns, and errors. Every sentence adds value; no fluff.
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?
Covers key aspects: purpose, parameter behavior, return format, errors. Output schema exists so detailed object description is unnecessary. Could mention authentication/network requirements but those are implicit for Airflow tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description compensates fully: explains conditional requirement (dag_id needed only with instance) and auto-resolution behavior of ui_url. Adds clarity beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Get DAG details and a UI link,' specifying the verb and resource. Distinguishes from sibling tools like airflow_list_dags (list vs get) and airflow_get_dag_run (different resource).
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?
Provides parameter guidance (provide one of instance/ui_url, dag_id required with instance) but lacks explicit when-to-use vs alternatives like airflow_list_dags or airflow_get_dag_run. Usage context is implied but not fully articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds useful behavioral details: the return type (dict with keys 'instances', 'default_instance', 'request_id') and error format (ToolError with JSON payload).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences, no wasted words, and clearly front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless list tool with rich annotations and an output schema, the description is complete. It specifies the response structure and error behavior, covering all needed context.
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?
There are no parameters, so schema coverage is 100%. The description does not need to add parameter information. It correctly omits irrelevant details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists configured Airflow instance keys, using a specific verb and resource. It distinguishes itself from sibling tools that list other entities like DAGs or runs.
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 description implies usage for discovering available instances, but lacks explicit when-to-use or when-not-to-use guidance compared to siblings. No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, making safety clear. The description goes beyond by detailing the return structure (task_instances array with fields, count, filters) and error handling (ToolError with compact JSON). This adds valuable behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured: a one-sentence summary, bullet-pointed parameter list, and a clear Returns section with an example JSON. Every part adds value, and the information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite 8 optional parameters and many siblings, the description covers the purpose, all parameters, return format, and error handling. The output schema further complements the return docs. No gaps remain for a list operation of this complexity.
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?
With 0% schema description coverage, the description compensates well by explaining each of the 8 parameters, including type coercions for limit/offset and case-insensitivity for state. However, it does not explicitly indicate which parameters are typically required (e.g., dag_id and dag_run_id) for meaningful results, leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'task instances within one DAG run', with a specific scope that distinguishes it from siblings like 'airflow_get_task_instance' (single instance) and 'airflow_list_instances' (potentially across DAGs). The mention of 'state and attempt log URLs' adds precision.
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 description implies usage for a specific DAG run by stating 'within one DAG run', but does not explicitly compare with alternatives or state when not to use it. No when-not or explicit alternative mentions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (destructiveHint=true), the description discloses that the tool sets is_paused=True, returns a specific response dict, and mentions error format (ToolError). It adds context about the side effect and return value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a single sentence for purpose followed by a clear bullet list of parameters and return values. Every sentence is necessary and well-structured, front-loading the action.
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?
Given the presence of an output schema and sibling tools, the description covers purpose, parameters, error behavior, and return format. It could mention effects on running tasks, but the description is largely complete for agent decision-making.
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?
With 0% schema description coverage, the description compensates by documenting each parameter: instance (optional, exclusive with ui_url), ui_url (optional, takes precedence), dag_id (required if ui_url not provided). This adds meaning beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Pause DAG scheduling (sets `is_paused=True` and returns UI link).' It specifies the verb (pause) and resource (DAG scheduling), differentiating it from sibling tools like airflow_unpause_dag.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use each parameter (instance, ui_url, dag_id) and their mutual exclusivity. However, it does not explicitly state when to use this tool versus alternatives like unpause_dag, though the name conveys the basic use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true. The description adds the destructive nature, dry_run safety mechanism (default true, set false to clear), return format, and error handling (ToolError with JSON payload). This provides behavioral context beyond annotations.
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 description is front-loaded with the purpose and well-structured with bullet points for parameters and returns. While necessary given the number of parameters, it is somewhat lengthy but without wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, no schema descriptions, but output schema exists), the description covers purpose, parameter usage, return values, and error handling comprehensively. It is fully sufficient for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates fully by listing all 10 parameters with brief explanations, including mutual exclusions and defaults. This adds essential meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('clear all task instances') and the resource ('within one specific DAG run'). It distinguishes from siblings like 'airflow_clear_task_instances' by scoping to a single DAG run.
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 description implies use for clearing a single DAG run but does not explicitly contrast with siblings or provide when-not-to-use guidance. It does specify mutual exclusivity of parameters and dry_run behavior, aiding correct invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare the tool as read-only, idempotent, and non-destructive. The description adds substantial behavioral context: large logs auto-tail, host-segmented responses are flattened, filtering order, parameter clamping, and return fields. No contradictions with annotations.
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 description is lengthy but well-structured with clear sections (log handling, filter order, parameters, returns). It front-loads the core purpose. Every sentence adds value given the tool's complexity; minor reduction could improve conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description comprehensively explains all return fields (log, truncated, auto_tailed, bytes_returned, etc.) and error handling. Given the tool's complexity (10 parameters, filtering logic), it is fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/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. It thoroughly explains each parameter: mutual exclusivity of instance and ui_url, defaults, type coercion, clamping, filter_level patterns, and context_lines behavior. This adds critical meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with 'Fetch task instance logs with optional filtering and truncation,' providing a specific verb (fetch) and resource (task instance logs). It clearly distinguishes from sibling tools like airflow_get_task_instance, which presumably returns instance metadata, not logs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states that the tool requires an explicit try_number and advises callers to first retrieve it via airflow_get_task_instance. It also details the filter order of operations, guiding when each parameter applies. However, it does not explicitly exclude scenarios where this tool should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![apache-airflow-mcp-server MCP server](https://glama.ai/mcp/servers/madamak/apache-airflow-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/madamak/apache-airflow-mcp-server)

Score Badge

Copy to your README.md:

[![apache-airflow-mcp-server MCP server](https://glama.ai/mcp/servers/madamak/apache-airflow-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/madamak/apache-airflow-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/madamak/apache-airflow-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server