monitor_delays

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

No annotations are provided, so the description carries full burden. It discloses that delayed flights are often already airborne (active status) rather than scheduled, explains this is correct data, and gives guidance on how to handle user preference—demonstrating full transparency.

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 long but efficiently front-loaded with trigger instruction, followed by purpose, use cases, parameter guidance, and status note. Every sentence adds value; minor redundancy could be trimmed but overall well-structured.

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 6 parameters (1 required), no output schema, and complex behavioral nuances, the description covers all necessary aspects: trigger, use cases, parameter usage, name resolution, and data interpretation. It explains the return format (delay minutes, new estimated time).

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 100% with descriptions, so baseline is 3. The description adds value by providing example values for 'delay', clarifying the resolution of names for airline/airport parameters, and explaining the 'type' parameter scope. Enriches 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 lists flights delayed beyond a threshold with optional filters, and includes trigger instructions and use cases that differentiate it from siblings like get_airport_schedule or track_live_flights.

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?

Explicit trigger instruction: 'use automatically whenever the user asks about delayed flights' with specific query patterns. Also directs to resolve airport/airline names first using other tools, and advises on status filtering based on user intent.

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