Skip to main content
Glama
call518

MCP-Airflow-API

by call518

delete_connection

Delete an Apache Airflow connection using its exact connection ID to remove obsolete or misconfigured entries and maintain accurate cluster connection settings.

Instructions

[Tool Role]: Deletes a connection.

Args: connection_id: Exact Airflow connection identifier.

Input Schema

NameRequiredDescriptionDefault
connection_idYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv3.7.2
  2. Removedv3.6.5
  3. Changed2 schema fields changedv3.6.6
    • addedInput schema / additionalProperties
      Added value: +false
    • removedInput schema / properties / connection_id / title
      Removed value: -"Connection Id"
  4. Addedv1.0.0

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 behavioral burden. It says only that the connection is deleted, with no mention of irreversibility, whether DAGs referencing the connection break, permission requirements, or error behavior for missing IDs — all critical for a destructive operation.

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 core statement is front-loaded and the total length is minimal. The 'Args:' block is templated scaffolding that largely restates the schema, but it costs little space.

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. However, for a single-parameter destructive tool with zero annotation coverage, the description omits the safety and side-effect context an agent needs before invoking it.

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 coverage is 0% and the single parameter is only typed as a string, so the description does add value by specifying it must be the 'exact Airflow connection identifier' (as opposed to a partial/pattern match). It does not clarify format (e.g., connection type prefix like 'aws_default') or case sensitivity.

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 gives a specific verb and resource ('Deletes a connection'), which is unambiguous on its own. It does not, however, explicitly distinguish itself from the other connection-level siblings (create_connection, update_connection, get_connection), relying on the name alone for that differentiation.

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 guidance on when to use this versus update_connection (modify) or when deletion is inappropriate. No prerequisites, no mention that the connection must exist, and no note that the connection_id should be obtained from list_connections/get_connection first.

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