The Airflow MCP server exposes 9 read-only tools for querying Airflow state. However, critical information is missing from the provided source code: actual input schemas, parameter definitions, and detailed descriptions are not visible. Tool definitions appear to exist in src/astro_airflow_mcp/tools/__init__.py, but the source snippet does not include the actual tool registration code, parameter schemas, or return type documentation. This forces conservative scoring. The tool names follow a reasonable verb_noun pattern (list_*, get_*), and descriptions are present but brief (30-60 chars, below the 194-char baseline). Without seeing the actual schemas, parameter types, and constraints, it is impossible to verify compliance with critical pattern requirements. The Dockerfile and Makefile show good development hygiene, but do not contain tool definitions.

• Expand all tool descriptions to 100-200 characters. Answer: What does it do? When should I call it instead of a similar tool? What does it return? Example: 'list_dags: List all available Airflow DAGs (workflows). Call this to discover available workflows before querying specific DAG runs or task states. Returns dag_id, owner, and last_modified for each DAG.'
• Document the complete input schema for each tool, including parameter names, types (string, integer, boolean), required vs optional, constraints (min/max, enums, patterns), and per-parameter descriptions. Use JSON Schema format with type definitions.
• Document the output/return schema for each tool. For list_* tools, show the structure of returned items (e.g., list_dags returns array of {dag_id: string, owner: string, last_modified: ISO8601}). Include a total_count or next_cursor field for pagination.
• Add pagination support (limit, offset or cursor) and result caps (e.g., max 50 DAGs per call) to list_dags, list_dag_runs, and list_tasks. Document the limit in the tool description.
• Add error handling guidance to tool descriptions: 'If a DAG is not found, the tool returns a list of similar DAG names. If Airflow API is unreachable, the error message will indicate network connectivity issues and suggest retrying.'
• Add natural-language identifier support where applicable. E.g., get_variables should accept variable_name (string) in addition to any internal variable_id. Accept Airflow connection names directly rather than requiring opaque internal IDs.

Inferred effective spec: <=2025-11-25.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry