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

Discloses the tool returns combined data (metadata, tasks, failures) and is read-only in nature. With no annotations, a clear behavioral description is provided, though it could explicitly state no side effects.

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

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

Well-structured with clear sections, bullet points, and front-loaded purpose. Every sentence adds value without redundancy.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers all necessary aspects: purpose, usage, parameters, and return values (described). With an output schema present, the description provides sufficient context for an AI agent to use the tool correctly.

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

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

Despite 0% schema coverage, the description explains both parameters ('dag_id', 'dag_run_id') with example values and context, compensating well for the missing schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the tool diagnoses issues with a specific DAG run, providing run details and failed tasks. Differentiates from sibling tools like 'get_dag_run' by emphasizing combined data and failure highlights.

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

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

Explicitly states when to use (troubleshooting failed runs) and provides example user queries. Implicitly indicates alternatives by describing its specialized diagnostic function.

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

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

Describes returned data (metadata, tasks, source code, errors) and states it combines multiple pieces in one call. With no annotations, this provides good transparency, but does not explicitly declare read-only nature.

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

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

Well-structured with sections for purpose, usage, args, returns. Slightly verbose in usage section but still efficient.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given one parameter, no annotations, and output schema exists, the description comprehensively covers purpose, usage, parameter, and return data.

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

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

Schema has 0% description coverage, but description includes 'Args: dag_id: The ID of the DAG to explore', fully clarifying the parameter's purpose.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states 'Comprehensive investigation of a DAG - get all relevant info in one call' with specific verb and resource. It distinguishes from siblings by noting it avoids multiple calls and is the preferred first tool.

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

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

Provides explicit when-to-use scenarios: when user asks 'Tell me about DAG X' or needs to understand structure before diagnosis. Does not explicitly exclude cases where a more specific tool is better, but implies general context.

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

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

No annotations provided, so description carries full burden. It describes the output structure and that it returns JSON, but does not mention authentication, permissions, or side effects. For a getter, it's adequate but not thorough.

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

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

Well-structured with bullet points and sections, front-loaded with purpose. However, the list of example queries is slightly verbose and could be shortened.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no parameters and presence of output schema, the description fully explains the output sections and per-setting details, making it complete for the tool's purpose.

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

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

No parameters in input schema, so baseline is 4. Description adds value by detailing the output sections and structure, exceeding the baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool gets Airflow configuration and settings, listing specific user queries and sections returned. It distinguishes from sibling tools (e.g., get_airflow_version) by focusing on config retrieval.

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

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

Explicitly states when to use with example queries, providing clear context. Does not mention when not to use, but given the tool's read-only nature, it's acceptable.

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

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

Despite no annotations, the description discloses the return fields (version, git_version) and explains its practical uses. It does not mention rate limits or permissions, but for a simple read operation with no side effects, the transparency about output and purpose is adequate.

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

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

The description is verbose due to a long list of example user queries and repeating similar phrases. While structured with sections, it could be more concise without losing clarity. Every sentence adds some value, but some redundancy exists.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no parameters and an existing output schema, the description is fully complete: it explains what the tool returns, why it's useful, and when to invoke it. It covers all necessary aspects for an agent to correctly select and use this simple retrieval tool.

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

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

The input schema has zero parameters, so the description bears no burden to explain parameters. Instead, it adds value by describing the return structure and use cases, exceeding the baseline of 4 for tools without parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it retrieves 'version information for the Airflow instance' and distinguishes itself from siblings like get_airflow_config and get_system_health. It provides specific examples of user queries that should trigger this tool, making its purpose unambiguous.

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

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

The description explicitly lists when to use the tool (e.g., when user asks about Airflow version) and provides context for its utility (API compatibility, feature availability, troubleshooting). It lacks explicit 'when not to use' guidance, but given no overlapping sibling tools for version info, this is less critical.

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

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

No annotations provided, so the description carries full burden. It does not disclose behavioral traits such as read-only nature, authentication requirements, rate limits, error handling, or potential side effects. Only describes what information is returned, not the behavior.

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

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

The description is front-loaded with purpose and use cases, but it is somewhat lengthy with a detailed list of return fields. This could be streamlined since an output schema exists, but the structure is logical and easy to scan.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool is a simple getter with one parameter and has an output schema, the description covers usage scenarios, parameter meaning, and return fields adequately. It does not address edge cases or error conditions, but for a straightforward retrieval tool it is sufficiently complete.

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

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

The input schema has 0% description coverage and only one parameter dag_id. The description adds a brief but clear explanation: 'dag_id: The ID of the DAG to get details for', which provides necessary context beyond the bare schema definition.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states 'Get detailed information about a specific Apache Airflow DAG' and lists numerous specific user queries, clearly distinguishing it from sibling tools like list_dags (listing all DAGs) or get_dag_run (specific run details).

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

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

Provides a comprehensive list of when to use the tool with example user queries, but does not explicitly mention when not to use it or suggest alternatives. However, the extensive examples make the use context clear.

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

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

No annotations provided, so description bears full burden. It comprehensively lists all returned fields and states output is JSON. It does not mention error handling, authorization, or read-only nature, but for a read operation this is adequate.

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

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

The description is structured with sections and bullet points, front-loading the purpose. It is thorough but slightly verbose; could be trimmed without losing meaning.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity, lack of annotations, and presence of output schema (implied by detailed field list), the description is complete. It covers usage guidance, parameter semantics, and return value details, enabling correct selection among 28 siblings.

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

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

Schema coverage is 0%, but the description provides clear meaning and examples for both parameters (dag_id and dag_run_id). It fully compensates for the missing schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states it gets detailed information about a specific DAG run execution. Use cases and examples distinguish it from siblings like list_dag_runs (list all runs) and diagnose_dag_run (diagnose issues).

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

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

The description provides explicit when-to-use scenarios with example user queries. It implicitly differentiates from alternative tools but does not explicitly state when not to use it or name alternatives directly.

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

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 correctly identifies this as a read operation (no mention of side effects) and describes the return fields. However, it does not disclose authorization requirements, error handling, or constraints like DAG existence, which would be helpful.

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

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

The description is somewhat verbose with bullet points and example queries. While helpful, it could be more concise. The front-loading of purpose is good, but the list of user queries takes up space that could be summarized more briefly.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema exists, the description adequately covers return values (content, file_token). It addresses the parameter and usage examples. With many sibling tools, the context is fairly complete, though it could mention prerequisite conditions like DAG existence.

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

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

With 0% schema description coverage, the description fully defines the sole parameter 'dag_id' as 'The ID of the DAG to get source code for'. This adds necessary clarity beyond the schema's type-only definition.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'get' and resource 'source code for a specific Apache Airflow DAG'. It provides explicit example queries that distinguish it from siblings like 'get_dag_details' or 'explore_dag'.

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

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

The description includes explicit 'when to use' scenarios with concrete user queries, making the tool's purpose clear. It lacks explicit 'when not to use' or alternative tool references, but the examples effectively guide usage.

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

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

No annotations are provided, so the description must fully disclose behavior. It explains the return format (JSON with counts by state) and the optional filtering. However, it omits details like time range, whether it's real-time or historical, permission requirements, or any rate limits. The description is adequate but not exhaustive, scoring a 3.

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

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

The description is well-structured: a one-line summary, bullet-pointed use cases, a list of return states, and an Args/Returns section. It is comprehensive yet concise, with every sentence contributing value. No wasted words.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema exists (though not shown) and the tool has only one optional parameter, the description covers purpose, usage, parameter, and return structure comprehensively. It leaves no obvious gaps for agent decision-making, earning a 5.

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

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

With schema description coverage at 0%, the description adds significant value by explaining the dag_ids parameter: it's optional, filters to specific DAGs, and defaults to all DAGs. This goes beyond the schema's simple type definition, earning a 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it gets statistics about DAG runs, specifying the verb 'Get' and the resource 'DAG runs' (aggregate stats). It effectively distinguishes from sibling tools like get_dag_details (single DAG) and get_dag_run (single run) by focusing on aggregate state counts. The use cases list further clarifies its role.

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

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

The description explicitly lists example queries that should trigger this tool (health, success/failure counts, summary, etc.), providing clear context. It does not mention when NOT to use it or name alternatives directly, but the implied scope is clear given the sibling tools, so it's slightly below a 5.

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

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

With no annotations, the description carries full burden. It discloses that the tool returns real-time information about capacity and utilization, and lists all return fields. No contradictions noted.

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

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

The description is well-structured with usage examples and return field definitions. Slightly verbose but front-loaded with purpose and no wasted sentences.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given an output schema exists, the description explains return values in detail. It covers the parameter, usage scenarios, and output, making it fully complete for a simple read tool.

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

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

Schema coverage is 0%, so description compensates. It explains the single parameter 'pool_name' with example 'default_pool', adding meaning beyond the schema's type only.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Get detailed information about a specific resource pool.' with specific verb+resource. It distinguishes from siblings like 'list_pools' by focusing on a single pool's details. Examples of user queries reinforce the purpose.

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

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

The description provides explicit 'when to use' examples mimicking user queries (e.g., 'Show me details for pool X'). It does not explicitly mention when not to use or alternatives, but the context is clear and specific.

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

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 discloses what data is returned (import errors, warnings, stats) and implies a read-only operation, but does not explicitly state it is non-destructive or idempotent. Lacks details on authentication or rate limits.

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

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

The description is structured with bullet points and front-loads the purpose. It is somewhat verbose but each sentence adds value. Could be shortened, but it is clear and well-organized.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has no parameters and is a simple health check, the description fully covers its behavior and return format. With the presence of an output schema (not shown but indicated), the description provides sufficient context for an agent to use the tool correctly.

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

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

The tool has zero parameters, so schema coverage is 100% by default. The description adds value by enumerating the specific data categories returned, which goes beyond the empty schema. A score of 4 is appropriate for providing meaningful return context.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: getting overall Airflow system health, listing specific components (import errors, warnings, DAG stats). The purpose is distinct from sibling tools like list_import_errors or explore_dag, as it provides a consolidated view.

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

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

The description provides explicit usage scenarios: when users ask about problems, for health checks, or starting investigations. It does not explicitly state when not to use it, but the context implies it's for high-level overviews, and alternatives like list_import_errors are more specific.

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

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

No annotations exist, so description carries full burden. It comprehensively lists all return fields (18 attributes) but does not mention error handling or permissions. Still, it transparently describes the tool's read-only behavior and output.

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

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

Description is well-structured with a clear purpose statement, usage examples, and a formatted list of return fields. Slightly lengthy but every section adds value; no unnecessary content.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (2 params) and absent output schema, the description fully compensates by detailing all return fields. It covers the essential information needed for an agent to invoke and interpret results correctly.

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

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

Schema coverage is 0%, so description must compensate. It provides brief explanations for dag_id and task_id ('The ID of the DAG containing the task', 'The ID of the task to get details for') but no additional details like formats, constraints, or examples. This is minimally adequate but not enriching.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves detailed information about a specific task definition in a DAG. It distinguishes itself from siblings like get_task_instance and get_task_logs by focusing on task definitions, aiding correct selection.

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

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

Provides explicit when-to-use guidance with example user queries. Lacks explicit when-not-to-use or alternative sibling names, but the examples sufficiently imply its scope.

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

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

With no annotations, the description carries full burden. It comprehensively explains the tool's behavior, listing all return fields and the output format. It implicitly indicates a read-only operation with no side effects.

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

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

The description is well-structured: a brief summary, usage examples, returned fields, args, and returns. It is front-loaded with the core purpose and remains concise without unnecessary detail.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (3 parameters, no nested objects) and the presence of an output schema (though not provided), the description covers all necessary context, including what the tool returns and how to use it.

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

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

The input schema provides only types and 'required' but no descriptions (0% coverage). The description compensates by explaining each parameter and providing an example for dag_run_id, adding significant semantic value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with specific verb and resource: 'Get detailed information about a specific task instance execution.' It distinguishes from siblings like get_task (task definition) and get_task_logs by focusing on execution details.

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

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

The description provides a bullet list of user queries that map to this tool, offering clear guidance on when to use it. However, it does not explicitly mention when not to use it or compare directly to sibling tools, which would improve clarity.

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

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 describes the return values (stdout/stderr, errors, timing), giving good behavioral insight. It does not explicitly state no side effects or authorization needs, but for a read-only log tool this is acceptable.

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

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

The description is well-structured with a clear lead sentence, bulleted usage examples, and an Args list. It is slightly verbose with the example queries, but remains clear and front-loaded.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 5 parameters (3 required) and no annotations, the description covers all necessary aspects: what the tool returns, parameter semantics, and usage context. It does not discuss potential errors or performance, but is complete enough for typical log retrieval.

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

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

Schema description coverage is 0%, but the description provides detailed, example-rich explanations for all 5 parameters (e.g., try_number: '1-indexed, use higher numbers for retries'). This adds significant value beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's verb ('Get logs') and resource ('task instance execution'). It differentiates from siblings like get_task_instance by focusing on logs, and provides user query examples that match the tool's function.

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

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

The description explicitly lists when to use the tool with specific user queries (e.g., 'Show me the logs for task X'). It does not state when not to use it or mention alternatives, but the context (sibling tools) and the examples implicitly provide guidance.

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

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

With no annotations, the description compensates by detailing the return structure (fields like dag_id, triggered_by_events, event_count, etc.) and explains the context of data-aware scheduling. It implies a read-only operation but does not explicitly state idempotency or lack of side effects.

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

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

The description is well-structured with bullet points and sections, covering key aspects without being overly verbose. Slightly more concise phrasing could be used, but it remains clear and scannable.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (2 params, no nested objects) and presence of an output schema, the description fully addresses purpose, usage, parameters, and return information. It also provides operational context (data-aware scheduling) which enhances understanding.

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

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

Input schema has 0% description coverage, but the description provides clear explanations for both required parameters: dag_id and dag_run_id, including an example format for dag_run_id. This adds significant meaning beyond the schema's type definitions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Get' and the resource 'asset events that triggered a specific DAG run'. It distinguishes this tool from siblings like list_asset_events and get_dag_run by focusing on causation for a specific run.

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

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

Provides explicit when-to-use guidance with example user queries ('What triggered this DAG run?', 'Why did DAG X start running?'), making it easy for an agent to select this tool for traceability questions.

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

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

Describes return values including potential masking of sensitive values, and explains that it's a read operation. Lacks mention of any side effects, but none expected.

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

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

Well-structured with headings and bullet points, but some explanatory text about variables could be shortened without losing value.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple getter with one parameter and no annotations, the description is complete, covering purpose, usage, and return format.

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

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

The single parameter 'variable_key' is fully described with its purpose and role, compensating for the 0% schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Get a specific Airflow variable by key' and provides specific example user queries, distinguishing it from list_variables.

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

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

Provides explicit usage examples and context about when to use, but does not explicitly mention when not to use or alternatives beyond the given examples.

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

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

With no annotations, the description carries the full burden. It explains that events are produced when a task updates an asset/dataset and that they can trigger downstream DAGs. The return fields are listed. However, it does not disclose pagination behavior or any failure modes, which would be a minor improvement.

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

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

The description is well-structured with sections for purpose, usage, return info, and args. It is slightly verbose but each sentence adds value. Could be tightened by merging the initial statement with the first usage line.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 4 optional parameters and an output schema (described in words), the description covers all necessary details: purpose, use cases, return fields, and parameter semantics. It is complete for an AI agent to invoke correctly.

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

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

Despite 0% schema description coverage, the description explains all four parameters in the 'Args' section with clear meanings (e.g., 'Filter events by the DAG that produced them'). The default for limit is also mentioned (100). This fully compensates for the missing schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists asset/dataset events with optional filtering. It uses a specific verb-resource combination ('List asset/dataset events') and distinguishes itself from sibling tools by focusing on events from task updates and data-aware scheduling triggers.

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

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

The description provides explicit usage scenarios starting with 'Use this tool when the user asks about:' and lists five concrete queries. This helps the agent understand when to invoke this tool versus others like get_upstream_asset_events or list_dags.

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

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

Despite no annotations, the description clearly indicates this is a read-only operation with no side effects, and details the returned fields (uri, id, consuming_dags, etc.). It provides sufficient behavioral context beyond the input schema.

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

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

The description is well-structured with clear sections and bullet points for return fields. It is moderately concise but includes necessary context; no wasted sentences.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given zero parameters, the description fully explains the tool's purpose and output. The presence of an output schema is complemented by a detailed textual description of return fields, making it complete for this simple tool.

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

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

With zero parameters and 100% schema coverage, the description adds meaning by detailing the return structure. Since there are no parameters to document, the baseline 3 is exceeded by the clear output specification.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves data assets and datasets tracked by Airflow, providing specific example queries. It distinguishes from related tools like list_asset_events and get_upstream_asset_events by focusing on assets themselves.

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

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

The description explicitly lists example user queries to guide usage, such as 'What datasets exist?' and 'Show me data dependencies'. While it does not explicitly exclude alternative tools, the examples cover primary use cases effectively.

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

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

No annotations are provided, so the description carries full responsibility for behavioral disclosure. It explicitly states that passwords are never returned for security reasons, describes the returned fields, and implies a read-only operation. This is thorough and honest.

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

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

The description is well-structured with bullet points and sections, front-loading the purpose and usage. It is slightly verbose but every sentence adds value. Slight improvement could be made by shortening the example queries list.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with no parameters and an output schema (though not provided in schema field, the description compensates), the description covers purpose, usage, return fields, and a security note. It is complete enough for an AI agent to use correctly.

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

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

The tool has zero parameters, so schema coverage is 100% and the description adds no parameter-specific detail. However, the description adds meaning by detailing the return fields and behavior (passwords excluded). Following the guidelines, baseline is 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose as retrieving connection configurations for external systems. It lists specific user queries that map to this tool, and the verb 'Get' with resource 'connection configurations' is precise. Sibling tools focus on DAGs, tasks, pools, etc., so this tool is well-distinguished.

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

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

The description provides explicit usage guidance by listing example user queries like 'What connections are configured?' and 'List all connections'. It does not explicitly state when not to use the tool, but the context is clear enough for an AI agent to select it appropriately.

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

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

Since no annotations are provided, the description carries the full burden. It explains the return format, fields, and sorting (most recent). However, it does not mention pagination, rate limits, or performance implications.

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

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

The description is well-structured with bullet points for use cases and a clear list of return fields. It is front-loaded with purpose and every sentence adds value.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no parameters and an existing output schema, the description is fairly complete, explaining return fields and sorting. However, it lacks mention of pagination or limits, which would be useful for a list tool.

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

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

The input schema has 0 parameters with 100% coverage, so the baseline is 3. The description adds value by explaining the output format and fields, which helps understand the tool's behavior even without parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves execution history and status of DAG runs, lists specific user intents, and distinguishes itself from sibling tools like get_dag_run (which retrieves a single run) and diagnose_dag_run.

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

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

The description explicitly lists use cases (e.g., 'show me recent runs', 'which runs failed/succeeded?') and implies context. However, it does not explicitly say when not to use it or mention alternatives like get_dag_run for single runs.

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

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

No annotations provided, so description fully handles behavioral disclosure. Describes that it returns comprehensive metadata and lists fields. Implicitly indicates read-only operation. 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.

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

Well-structured with bullet points and clear sections. Front-loaded with purpose. Could be slightly more concise, but no unnecessary repetition.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given zero parameters and presence of an output schema, description sufficiently covers return structure and usage. Missing mention of potential limits or pagination, but not critical for a list-all tool.

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

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

Input schema has zero parameters, so description does not need to add parameter information. Baseline score of 4 is appropriate as no additional detail required.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states 'Get information about all Apache Airflow DAGs' and provides specific user queries that trigger this tool. It effectively distinguishes from sibling tools like get_dag_details (single DAG) and list_dag_runs (runs).

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

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

Explicitly instructs when to use with example queries like 'What DAGs are available?' and 'Show me the workflows'. Does not explicitly mention when not to use or alternatives, but the examples are clear and sufficient.

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

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

No annotations are provided, so the description must cover behavior. It states it returns warnings and lists the fields, but omits details like whether it is read-only, required permissions, or potential rate limits. The output schema reduces the burden slightly.

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

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

The description is fairly verbose with bullet-like examples and listing return fields. It could be more concise while maintaining clarity. The structure is functional but not optimized.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (no parameters, output schema exists), the description covers the output fields and use cases adequately. It could mention whether warnings are cumulative or from a specific time period.

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

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

The input schema has zero parameters with 100% coverage, so the description does not need to add parameter info. It correctly derives a baseline of 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it retrieves warnings and issues from DAG definitions. The usage examples explicitly list user queries that map to this tool, distinguishing it from siblings like list_dag_runs or list_import_errors.

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

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

The description provides explicit when-to-use scenarios with natural language examples. However, it does not mention when not to use this tool or explicitly compare to alternatives like list_import_errors.

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

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 discloses the return fields (import_error_id, timestamp, filename, stack_trace) and explains the causes of import errors. It implies a read-only operation but does not discuss potential limitations like pagination or performance. Still, it is adequately transparent.

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

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

The description is longer than necessary, with repeated information (e.g., causes of import errors are listed twice). The first sentence is clear, but the bulleted examples could be condensed. Some sentences do not add new value.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the low complexity (no parameters, output schema present), the description is fairly complete. It covers purpose, typical use cases, causes, and return fields. It does not mention behavior for empty results or error cases, but that is minor.

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

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

The input schema has zero parameters, so coverage is vacuously 100%. The description adds value by explaining the output fields beyond the schema, which is the only semantic context needed. Baseline is 3, but the extra output detail justifies a 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the purpose: 'Get import errors from DAG files that failed to parse or load.' It uses a specific verb-resource pair and distinguishes from sibling tools (none of which list import errors). The examples reinforce the specific resource.

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

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

The description includes a list of explicit user queries that map to this tool, providing clear usage context. However, it does not mention when not to use it or provide alternative sibling tools for related issues (e.g., diagnose_dag_run for run failures).

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

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

No annotations provided, but description fully discloses behavior: it returns information about all discovered plugins, lists return fields (name, hooks, executors, etc.), and implies read-only nature. No side effects mentioned, but appropriate for a list tool.

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

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

Description is moderately long but well-structured with bullet points and example queries. Each sentence adds value, though could be slightly more concise. Front-loaded with purpose.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (list with no parameters) and presence of output schema (described in detail), the description is complete. Covers purpose, usage triggers, behavioral details, and return fields with no gaps.

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

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

Input schema has zero parameters, so schema description coverage is 100% trivially. Description adds no parameter info (none exist), which is fine. Baseline for zero-parameter tools is 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states 'Get information about installed Airflow plugins' with specific verb and resource. Provides example user queries that map directly to this tool, distinguishing it from siblings like 'list_providers' or 'list_dags'.

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

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

Explicitly lists when to use via example user questions (e.g., 'What plugins are installed?', 'Is plugin X installed?'). Provides context on what plugins are, but does not explicitly state when not to use or compare to alternatives.

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

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

No annotations are provided, but the description fully discloses that this is a read-only list operation. It describes the returned fields and their meanings, and implies no side effects.

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

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

The description is well-structured: a summary line, usage examples, a brief explanation of the resource, and a clear list of return fields. Every sentence is informative and concise.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no parameters and an output schema present, the description provides sufficient detail about the return fields and overall purpose. It covers what an agent needs to know to use this tool correctly.

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

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

There are zero parameters, so the description cannot add parameter semantics. The baseline is 4 per guidelines, and the description does not need to elaborate further.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Get resource pools' and immediately lists example user questions. It is specific to listing all pools, which distinguishes it from get_pool (singular).

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

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

Explicitly lists when to use the tool with example questions. Also explains the concept of pools and their purpose, giving context for appropriate usage.

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

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

With no annotations, the description carries full burden for behavioral disclosure. It explains the tool returns a JSON list with fields (package_name, version, description, provider_info), which is helpful. However, it lacks details on edge cases (e.g., empty result), potential side effects, or authentication requirements, leaving some behavioral aspects implied.

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

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

The description is concise, front-loaded with the main purpose, and uses bullet points to enumerate user queries and return fields. Every sentence adds value without redundancy.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given zero parameters and an output schema, the description adequately covers the tool's functionality, return structure, and usage examples. It is complete for the tool's complexity.

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

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

The input schema has no parameters, so schema coverage is effectively 100%. The description adds no parameter-specific semantics, but none are needed. According to guidelines, 0 parameters earns a baseline of 4, which is appropriate here.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves installed Airflow provider packages. It lists specific user queries that trigger this tool (e.g., 'List all providers', 'Is the AWS provider installed?'), making its purpose unambiguous and distinct from sibling tools.

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

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

The description explicitly enumerates when to use the tool with example user questions, providing strong contextual guidance. It does not list when not to use it or mention alternatives, but the context is sufficiently clear for decision-making.

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

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

No annotations are provided, so the description bears the full burden. It states the tool returns a list of tasks with fields like task_id, owner, etc., but does not disclose behavior on missing DAG, errors, or side effects. Adequate but not thorough.

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

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

The description is well-structured with a clear opening, bullet-pointed examples, and return fields. It is slightly verbose but every sentence contributes value. Front-loaded with purpose.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple interface (one required parameter, list return), the description covers purpose, parameter, and return fields. There is an output schema, so return details need not be expanded. Minor missing error contexts but sufficient overall.

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

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

The only parameter dag_id is described as 'The ID of the DAG to list tasks for', adding meaning beyond the schema's type and required flag. With 0% schema description coverage, this explanation is valuable.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Get all tasks defined in a specific DAG' with a specific verb and resource. It distinguishes from siblings like get_task (single task) and explore_dag (different scope).

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

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

Provides explicit query examples such as 'What tasks are in DAG X?' and 'Show me the tasks in this workflow'. It does not explicitly state when not to use the tool, but the context is clear for its intended use.

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

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

No annotations exist, so the description carries full burden. It discloses that sensitive variable values may be masked, and describes the return structure. It implies a read-only operation (no side effects). It does not contradict any annotations.

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

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

The description is well-structured with a clear opening, usage examples, explanation, and return details. While slightly verbose, each sentence serves a purpose and contributes to clarity.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no parameters and no annotations, the description is fairly complete: it explains what variables are, when to use, return format, and masking behavior. It lacks mention of pagination limits, but for a simple list tool this is acceptable.

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

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

The input schema has no parameters (0 params), so the baseline is 4. The description adds value by explaining the return fields and the security note about masking, which compensates for the lack of parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Get all Airflow variables (key-value configuration pairs)', with specific verb and resource. It lists example user queries that directly map to the tool's functionality. This distinguishes it from siblings like 'get_variable' by implying it returns all variables rather than a single one.

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

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

The description provides explicit usage guidance: 'Use this tool when the user asks about:' followed by concrete examples. It does not mention when not to use it or alternatives like 'get_variable', but the context is clear and helpful.

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

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

With no annotations provided, the description carries full burden and thoroughly explains behavioral traits: no new scheduled runs, current tasks complete, manual triggers still possible, UI indicator, and that it's a write operation modifying state until unpaused.

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

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

The description is front-loaded with the primary action and uses multiple paragraphs effectively. However, the list of user queries could be slightly trimmed without losing clarity.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simplicity of the tool (1 param, output schema present), the description fully covers the purpose, behavior, return value, and usage guidance. No missing aspects are apparent.

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

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

Schema coverage is 0%, but the description adds an 'Args' section with dag_id and an example value, providing context beyond the schema's type and required fields. While minimal, it adequately clarifies usage for the single parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool pauses a DAG to prevent new scheduled runs, providing a specific verb-resource pair. It lists example user queries like 'Pause DAG X' which distinguishes it from siblings like unpause_dag.

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

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

The description explicitly lists when to use this tool (e.g., user asks to pause, disable, turn off scheduling), making context clear. However, it does not explicitly exclude alternatives or mention when not to use, though the sibling unpause_dag is implied.

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

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

No annotations provided, so the description carries full burden. It explicitly states this is a write operation that modifies Airflow state by creating a new DAG run, and lists return fields. It does not detail permissions or side effects beyond creation, but is transparent enough for basic use.

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

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

The description is well-structured with a clear action statement, example queries, notes, and return field list. It is slightly verbose but every section adds value. Front-loaded with core purpose.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is complete: it explains purpose, usage context, parameter meaning, return value fields, and behavioral notes. Despite the output schema existing but not provided here, the description's own return field list is thorough. For a moderately complex tool with 2 parameters and a clear action, this description fully covers the agent's needs.

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

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

Schema coverage is 0%, but the description compensates by explaining both parameters: dag_id as the DAG ID string and conf as an optional config dictionary with context explanation. This adds meaning beyond the raw schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it triggers a new DAG run and provides many example user queries. However, it does not differentiate from the sibling tool trigger_dag_and_wait, which slightly reduces clarity.

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

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

The description lists explicit when-to-use scenarios with example user requests. It could be improved by noting when not to use this tool (e.g., if waiting for completion is desired, use trigger_dag_and_wait instead).

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

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

With no annotations provided, the description fully carries the burden. It explicitly states 'This is a BLOCKING operation', describes internal steps (trigger, poll, return), default timeout, and details on failed tasks. 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.

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

The description is well-structured with bullet points and clear sections. It is front-loaded with purpose. However, it is slightly verbose; some sentences could be combined. Still highly effective.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (blocking, polling, timeout, failure handling), the description is thorough. It explains the process, return fields, and even though an output schema exists, the description adds context. No gaps for an AI agent.

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

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

Despite 0% schema description coverage, the description adds rich meaning to all three parameters: `dag_id` with example, `conf` behavior description, and `timeout` default. This significantly aids an AI agent in understanding parameter usage beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's action: 'Trigger a DAG run and wait for it to complete before returning.' It provides specific verb and resource, distinguishes from sibling `trigger_dag` by explicitly noting the blocking behavior, and includes example queries that match common user requests.

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

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

The description explicitly lists example queries for when to use this tool and advises against it for long-running DAGs by suggesting `trigger_dag` and `get_dag_run` as alternatives. This clear when-to-use and when-not-to-use guidance is exemplary.

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

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

No annotations are provided, so the description carries the burden. It states it's a write operation, modifies Airflow state, and schedules new runs. It could mention permissions or catchup implications, but overall it's transparent.

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

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

The description is well-structured: a clear purpose sentence, bullet points for usage scenarios, consequences, and an important note. It is concise yet comprehensive.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the single parameter and existing output schema, the description covers everything needed: usage hints, behavioral effects, and return value format ('JSON with updated DAG details showing is_paused=False').

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

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

Only one parameter (dag_id) with schema coverage 0%, but the description adds an example ('example_dag') and context, which provides meaning beyond the schema's type definition.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Unpause a DAG to allow scheduled runs to resume.' It uses a specific verb (unpause) and resource (DAG), and distinguishes from siblings like pause_dag and trigger_dag.

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

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

The description provides explicit usage examples (e.g., 'Unpause DAG X') and explains what happens when unpaused. It does not explicitly mention when not to use or alternatives, but the context is very clear and helpful.

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