faa-traffic-delays-mcp-server

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

Annotations cover the safety profile (readOnly, idempotent, openWorld), so the description's job is to add beyond them — and it does: advisory numbers restart at 1 each UTC day (a real keying pitfall), older advisories remain available, and the payload contains program rate by hour, delay assignment mode, scope, comments, and plan constraints/runway closures.

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?

Three sentences, front-loaded with the core action, then sourcing, then what the returned text adds. No filler; every clause carries routing or content information.

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?

With an output schema present, return-value detail is unnecessary, and for a 2-param read tool the description fully covers invocation: input provenance, numbering/date semantics, data retention, and value over the status endpoints.

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 100% and the schema already documents accepted alternate formats (MM/DD/YYYY, 'ADVZY 082', '082'). The description adds only the pairing 'by its number and UTC date', so the schema does the heavy lifting and the baseline of 3 applies.

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?

States a specific verb and resource with its identifying keys: 'Get the full text of one ATCSCC advisory by its number and UTC date.' It is immediately distinguishable from the list/status siblings it names, so an agent can route correctly without opening a schema.

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 says where the required inputs come from (rows from faa_delays_list_advisories; advisory references returned by list_active_events, get_airport_status, and get_operations_plan) and when this tool is needed over the status feeds ('what the status feed omits'). That is when-to-use plus alternatives, with no inference required.

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?

Annotations already cover readOnly/openWorld/idempotent, and the description adds substantial behavior beyond them: coordinate provenance (feed vs. NASR directory fallback), ARTCC on every row, inclusion of includedFacilities/departureScopeNm semantics, rejection of unknown codes, and the fact that runway configuration exists only for feed-listed airports. This is rich, non-redundant disclosure.

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?

It is front-loaded: purpose first, then per-airport specifics, then identifier rules, then feed limitations. Every sentence carries operational weight for an agent deciding whether and how to call the tool.

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?

With annotations covering the safety profile and an output schema present, the description still supplies the missing context an agent needs - code validation/rejection, the no_active_events outcome, and the coordinate-source fallback. Nothing required to call it correctly is absent.

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% and the schema already documents accepted formats, trimming/uppercasing, dedup of FAA/ICAO equivalents, and the 25-airport processing cap. The description restates the code formats and rejection rule without adding new parameter-level meaning, so the baseline 3 applies.

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 opens with a specific verb and resource ('Get the current FAA traffic management status for one or more US airports') and enumerates exactly what the response contains (headline status, active events, runway config, arrival rate). An agent can immediately distinguish this from the sibling list/advisory 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?

It clearly frames when this tool applies (per-airport status including events and runway config) and gives decisive edge-case behavior: unknown non-US codes are rejected and known airports absent from the feed return no_active_events. It does not, however, explicitly contrast with siblings like faa_delays_list_active_events, so the routing guidance stops short of 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?

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: this is a forward-looking summary ('expected later in the day') and it explicitly discloses that it omits active constraints and runway closures available elsewhere.

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?

Two sentences, front-loaded with what is returned and followed by the escalation path to the advisory. The first sentence is a dense run-on list, but each item earns its place by telling the agent what fields to expect.

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?

An output schema exists, so return-value documentation is not strictly required, yet the description still scopes the response (summary vs. full advisory text). Combined with the annotations, an agent has enough to call this correctly; the only shortfall is absent guidance against the other four 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?

The tool takes zero parameters, so the baseline of 4 applies. The description correctly implies a no-argument call by describing a global snapshot rather than anything filterable, and adds no misleading parameter expectations.

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?

States a specific verb and resource ('Get the FAA Command Center's current operations plan') and enumerates the contents: terminal programs, en-route initiatives, UTC times, likelihood, and ATCSCC announcements. It explicitly distinguishes itself from faa_delays_get_advisory by describing itself as a summary that the advisory expands upon.

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?

Names the alternative sibling (faa_delays_get_advisory) and the condition that selects it: when the full plan text, active constraints, or runway closures are needed rather than this summary. It gives no guidance versus the other siblings (get_airport_status, list_advisories), so routing is clear but incomplete.

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?

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered. The description goes beyond that by disclosing the exact sort order (closures, ground stops, GDPs and AFPs by average delay, delays by band maximum, NOTAMs, deicing) and the payload each row carries (reason, delay figures, times, advisory reference), which materially shapes how an agent reads the result. It says nothing about rate limits or freshness/caching of the feed.

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?

Two sentences, with the scope-and-content statement front-loaded ahead of the sibling routing. The long parenthetical sort-order enumeration is dense but does real work for result interpretation; there is no filler.

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?

With an output schema present, the description need not explain return values, and it still covers scope, ordering and onward navigation. Schema coverage, annotations and output schema together leave no gap an agent needs to call this 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 description coverage is 100% and the single optional event_types parameter is fully documented there, including aliases, comma-separated strings, case-insensitivity, and the note that countsByType always covers the whole feed. The prose adds no additional meaning about the filter, so the baseline 3 applies.

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?

States a specific verb and resource with explicit scope ("every active FAA traffic management event across the National Airspace System") and enumerates the eight event classes it returns. It is unmistakably distinct from siblings that fetch a single airport, an advisory, or the operations plan.

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?

Names the alternative for a concrete case: "Use faa_delays_get_airport_status for the full detail of one airport, including its GDP delay profile and runway configuration." It also routes the agent onward to faa_delays_get_advisory via the advisory reference carried in each row, so the when-to-use-this-vs-that decision is spelled out rather than inferred.

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?

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so safety profile is covered. The description adds genuine behavioral context: newest-first ordering, inclusion of inactive/past advisories, and the exact row contents (advisory number, control element, subject, title lines, send time). It omits rate limits or pagination edge behavior, but the added context is meaningful.

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?

Front-loads the core action and scope in the first clause, and every sentence carries information. However, it is a very dense, comma-heavy run-on that could be split for easier scanning, slightly reducing readability.

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 filtered, paginated list tool with a 100%-covered schema, output schema, and full annotations, nothing essential is missing. The description even explains row fields and the cross-reference to the full-text tool, exceeding what the structured fields require.

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 100%, so the schema already documents every parameter in depth, including enum synonyms and the DCC/ICAO forms. The description largely restates these; its only real addition is that filters combine before limit/offset paging. Baseline 3 is appropriate when the schema does the heavy lifting.

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?

States a specific verb (List) and resource (ATCSCC advisories) with explicit scope: advisories issued on one UTC date, newest first, from the per-date index. The enumeration of advisory kinds (ground stops, reroutes, flow constrained areas, operations plans, CDM compression) and the 'NAS Status feed does not carry' clause let an agent distinguish it from siblings without opening the schema.

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?

Gives clear context for use — it covers historic/inactive advisories and per-date index entries the NAS Status feed lacks — and routes the agent to the sibling faa_delays_get_advisory to open full text. It does not explicitly state when not to use it versus list_active_events or get_operations_plan, so it stops short of full when/when-not coverage.

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?

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safe/idempotent profile is covered. The description adds that pacing_airports data is 'read live', hinting at freshness behavior, but that detail is largely duplicated in the schema and no other behavioral traits (caching, response size, rate limits) are disclosed.

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?

A single front-loaded sentence that leads with the high-value framing ('decode the vocabulary the other faa_delays tools return'). It is tightly written, though the enumerated topic list partially duplicates the schema's enum, making it slightly longer than strictly necessary.

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?

An output schema exists, so return values need not be explained, and the enum fully specifies the input. For a single-enum reference-lookup tool the description is nearly complete; only minor behavioral detail (freshness/scope of the 'read live' data) is left implicit.

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 100% and the single `topic` enum is documented in full detail with per-value meanings. The description's topic list mirrors the enum without adding syntax or format guidance beyond it, so the schema does the heavy lifting and baseline 3 applies.

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?

States a specific verb ('Decode the vocabulary') and names the exact resource: reference data for event types, terms, ARTCC codes, pacing airports, and identifier formats. It explicitly distinguishes itself from the sibling tools by describing itself as the decoder for what 'the other faa_delays tools return'.

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 framing 'decode the vocabulary the other faa_delays tools return' clearly signals when an agent should reach for this tool: when it needs to interpret opaque codes from the sibling tools. It stops short of stating exclusions or naming a specific alternative, so it is clear context rather than explicit routing.

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