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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds valuable behavioral context: it returns only a count, not the flights themselves, and it clarifies the query syntax family. It does not describe pagination or error behavior, but for a count tool with read-only annotations, the added context is solid.

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 with zero waste. The core behavior is front-loaded, the syntax distinction is stated immediately, and the example is compact. Every sentence earns its place.

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 count tool with 2 parameters, 100% schema coverage, and read-only annotations, the description is nearly complete. It explains the return shape, the syntax family, and gives an example. The only minor gap is that it doesn't explicitly state what happens with an empty result or invalid query, but that is not essential for an agent to call it 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 100%, so the schema already documents both parameters. The description adds meaning by clarifying that the query parameter uses the simplified syntax and by giving a concrete example ('-airline UAL -belowAltitude 30000'). It also explains the view parameter's compact/full distinction in the schema itself, so the description's added value is moderate but real.

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 states a specific verb ('Count'), a resource ('flights'), and a clear scope ('matching a query without returning the flights themselves'). It also explicitly distinguishes itself from fa_search_flights and fa_search_flights_advanced by naming the syntax family it uses, so an agent can tell it apart from siblings without opening schemas.

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 says it uses the SIMPLIFIED '-key value' syntax, same as fa_search_flights, and NOT the structured grammar of fa_search_flights_advanced. This gives clear when-to-use and when-not-to-use guidance, and names the alternative tools. The example further anchors correct 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?

The description adds substantial behavioral context beyond the annotations: the two-step confirmation flow, the fact that the first call makes no network request, the confirmToken repeat-call requirement, and the 401 failure on the free tier. These details are not visible in readOnlyHint/openWorldHint/idempotentHint and significantly help an agent act correctly.

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 three sentences and front-loads the core purpose before the confirmation nuance. It is somewhat dense, especially the MCP_CONFIRM_MODE reference, but every sentence contributes necessary information and none is wasted.

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 15 parameters, no output schema, and sparse annotations, the description covers the most critical operational concerns: confirmation behavior, network-call semantics, token reuse, and auth requirements. It does not describe the final success response or which parameter combinations are required to actually create an alert, so it is not fully complete, but it is strong 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?

Schema coverage is 100%, so the baseline is 3. The description adds real value beyond the schema by explaining the confirmToken protocol: it must not be sent on the first call, must not be invented or reused, and must accompany a repeat call with the same arguments. This is critical usage semantics that the schema alone does not fully convey.

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: 'Create a flight alert on your AeroAPI account.' This clearly distinguishes the tool from siblings like fa_update_alert, fa_delete_alert, and fa_list_alerts. The rest of the description reinforces the creation role with confirmation-flow 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 clear context for when to use the tool: creating a flight alert, requiring user confirmation, and needing a Standard or Premium tier. It does not explicitly point to alternative tools for update/delete/list operations, but the sibling names and the creation-focused wording make the intended use 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?

The description discloses the two-phase confirmation behavior in detail: the first call returns a preview and confirmToken with no network call, and only a repeat call with that token proceeds. It also warns about the 401 on the free Personal tier, adding valuable context beyond the annotations without contradicting readOnlyHint=false or idempotentHint=true.

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 purpose is front-loaded in the first sentence, and confirmation mechanics plus tier requirements follow in compact, well-organized prose. Every sentence contributes essential operational information without redundancy or 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?

For a destructive delete operation, the description covers the confirmation protocol, the no-op first call, the token-based second call, and the tier limitation. Together with the detailed schema, an agent has enough context to invoke the tool safely and correctly. No critical behavioral gap remains.

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 already provides 100% parameter coverage, including a thorough explanation of confirmToken and its restrictions. The description reinforces the role of id and the token flow but does not add meaning beyond what the schema already states. Baseline 3 is appropriate for this level of 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 opening sentence, 'Delete a flight alert by id,' uses a specific verb and resource, making the tool's purpose unmistakable. It is clearly distinct from sibling tools like fa_list_alerts, fa_get_alert, fa_create_alert, and fa_update_alert. No sibling competes for this delete action.

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 clearly implies this tool should be used when an existing flight alert must be removed by its id. It also provides important preconditions: confirmation is required and a Standard/Premium tier is needed. It does not explicitly name alternatives or when-not conditions, but the delete semantics are unambiguous from 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds the premium-tier subscription requirement and the 'predicted data' nature, which are useful but not extensive behavioral disclosures. No contradiction with 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?

Two sentences with no waste: the first defines the tool and its relationship to a sibling, the second gives a critical subscription caveat. Both are front-loaded and directly useful.

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 read-only search tool with full schema parameter descriptions and annotations covering safety, the description is nearly complete. It explains the core purpose, distinguishes from siblings, and flags the premium requirement. The only minor gap is not describing the response structure, but since there is no output schema and it's a search 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?

Schema coverage is 100% – all four parameters have detailed descriptions, including the view enum, query syntax, cursor paging, and max_pages billing cap. The description adds marginal value by referencing the Boolean query language similarity to fa_search_flights_advanced, but essentially the schema carries the parameter semantics.

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 ('search'), the resource ('flights'), and the specific nature ('predictive' via Foresight), and explicitly differentiates it from the sibling fa_search_flights_advanced by noting it returns predicted data. This distinguishes it from the many sibling flight-search 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 tells the agent that this is like fa_search_flights_advanced but for predicted data, and importantly warns that it requires a premium subscription (expect 402/403 otherwise). This gives clear context on when to use it, though it doesn't explicitly state when not to use alternatives beyond the subscription caveat.

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=true and openWorldHint=true, and the description's 'Get' is consistent with a read-only operation. The description adds no additional behavioral context beyond the schema, such as response shape or limitations, which is acceptable given annotations cover the core safety profile.

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 sentence that front-loads the verb, target resource, and lookup key with no filler or schema duplication. It is as concise as the definition can be for this simple 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?

For a two-parameter read-only lookup with full schema coverage and safety annotations, the description is nearly complete. It does not describe the return value shape, but there is no output schema and the tool's low complexity makes that omission 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?

Schema description coverage is 100%: both 'ident' and 'view' are explained, with 'view' getting a detailed description. The tool description's registration example adds no real meaning beyond what the schema already states, so it stays at the high-coverage 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 a specific verb and resource: it gets the registered owner of an aircraft by tail number/registration. This distinguishes it from the flight, airport, and operator siblings, so there is no ambiguity about what this tool does.

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 intended use case is implied clearly: call this when you need an aircraft's registered owner by its registration. However, the description does not explicitly state when not to use it or name any alternative sibling, so the usage guidance is inferred rather than stated.

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=true and openWorldHint=true, so the description does not need to repeat these. It adds minimal behavioral context beyond the input format, such as clarifying that the tool returns 'details' but without specifying the response structure or error behavior. Given the annotations cover the main safety and data assumptions, this is adequate but not rich.

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 a single sentence that front-loads the primary purpose and input format. There is no redundant information, and it achieves maximum clarity with minimal 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?

For a tool with only two parameters (one required) and no output schema, the description is nearly complete. It explains the required input format and implies the return type ('details'). However, it does not mention the optional 'view' parameter or what fields are included, though these are covered in the schema. Given the tool's simplicity, this is a minor gap.

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 clear descriptions for both parameters: 'id' as 'Airport code (ICAO/IATA/LID)' and 'view' with a detailed explanation of compact/full behavior. The description repeats the code formats with examples (KJFK, JFK) but adds no new semantic meaning beyond the schema. This matches the baseline for full 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 the verb 'Get', the resource 'airport', and the input method 'by code (ICAO like KJFK, IATA like JFK, or LID)'. This unambiguously identifies the tool's function and distinguishes it from sibling tools like fa_list_airports (listing) or fa_resolve_airport (code resolution).

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 implies the use case (retrieve airport details by code) but does not explicitly state when to prefer this over related tools such as fa_get_airport_flights or fa_get_airport_weather. No exclusions or alternatives are mentioned, leaving the agent to infer the appropriate context from the tool name alone.

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?

The annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds 'current' and the all-or-one scoping behavior, but it does not disclose pagination behavior, response shape, or data-source caveats beyond what the schema already states.

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 tight sentence that front-loads the core purpose and embeds the key selection condition without wasted words. Every part of the description earns its place.

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 four optional parameters, a complete schema, and strong read-only/open-world annotations, the description is sufficient for basic selection and invocation. It does not cover response fields or pagination details, but the schema thoroughly documents the parameters and the annotations cover the operational safety profile.

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 fully documents `id`, `view`, `cursor`, and `max_pages`. The description's mention of `id` and 'all delayed airports' adds little beyond the schema's own 'Airport code to scope to a single airport (omit for all delays)'.

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 uses a specific verb ('Get') and resource ('current airport delays') and clearly defines the two invocation scopes: all delayed airports, or a single airport when `id` is given. This makes it easy to distinguish from sibling tools like fa_get_airport_flights or fa_get_airport_weather, which address different resources.

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 gives clear context for choosing between 'all' and 'one via `id`', but it does not explicitly say when to prefer this tool over the many sibling airport/flight tools. There is no mention of alternatives or exclusions, so an agent must infer the scope from the resource name.

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 provide readOnlyHint=true and openWorldHint=true. The description adds context about the response shape (specifically the metrics returned) and the schema's description of 'view' adds behavioral detail about field projection and the risk of dropping fields, which goes beyond 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 a single concise sentence that front-loads the key purpose and metrics. It avoids fluff, though it could be slightly more structured to note input requirements, but it's already 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?

For a read-only count tool, the description is sufficient to understand what it returns. The schema explains both parameters fully. No output schema, but the returned fields are enumerated. Potential missing info like exact response format is minor given the low 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?

Schema covers parameters 100%: 'id' has a pattern and description, 'view' explains the enum options in detail. The description slightly adds by listing the metrics, but the schema already explains the 'view' parameter's purpose comprehensively.

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 current flight counts at an airport, listing the exact metrics returned (departed, enroute, scheduled_arrivals, scheduled_departures). It distinguishes from sibling tools like fa_get_airport, fa_get_airport_delays, and flight-specific tools by focusing on aggregate counts.

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 implies it's for aggregate counts at an airport but doesn't explicitly state when to use this vs. alternatives like fa_get_airport_flights which might list flights. However, the metric names clarify its purpose for counts, and the schema description for 'view' provides usage guidance on response shape.

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 and openWorldHint, and the description is consistent with that (read-only 'Get'). The description adds a small behavioral scoping detail about board types, but does not disclose pagination cost, time-window defaults, or response characteristics beyond what the annotations and schema provide.

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 states the purpose and lists board options with zero filler. Every word earns its place.

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 tool with eight parameters and no output schema, the description is deliberately minimal. It does not explain default time-window behavior, pagination or per-page cost, or the response shape of a 'flight board'. However, the rich schema parameter descriptions and readOnly annotations cover most operational gaps, making the definition adequate but not 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?

Schema description coverage is 100% and all eight parameters, including enums and billing notes, are already documented. The description only repeats the board enum values and does not add meaning beyond the input schema, so 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?

The description clearly identifies the tool as 'Get a flight board for an airport' and enumerates the board variants (all/arrivals/departures/scheduled_arrivals/scheduled_departures), distinguishing it from sibling tools such as fa_get_airport_flight_counts, fa_get_airport_delays, and fa_get_airport. The verb and resource are specific and 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 provides no guidance on when to choose this tool over siblings like fa_get_flights, fa_get_airport_flight_counts, or fa_get_airport. It does not mention alternatives, exclusions, or conditions that would route an agent to a different tool, leaving such decisions to inference.

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 and openWorldHint. The description adds useful return-content context (aircraft types, counts, filed altitudes) but does not describe behavioral traits such as sorting, pagination effects, or aggregation limits. This is acceptable given the annotations but does not go beyond them significantly.

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 sentence front-loads the action, resource, and key output details. There is no filler, repetition, or unnecessary explanation.

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 read-only aggregation tool with rich parameter schema descriptions, annotations, and no output schema, the description provides the key return concepts. An agent has enough context to select and invoke 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?

Schema description coverage is 100%, and the description only restates the origin/destination concepts already fully documented in the schema. It adds no parameter-level meaning beyond what the schema provides, so the baseline score of 3 is appropriate.

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?

Identifies a specific verb and resource: get the most popular routes between an origin and destination airport. It also names the returned data (aircraft types, counts, filed altitudes), which distinguishes it from sibling tools like fa_get_flight_route or fa_get_airport_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?

The description clearly implies when to use it: when the caller wants aggregate route popularity between two airports. It does not explicitly name alternatives or exclusions, so it falls just short of full 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?

Beyond the readOnlyHint and openWorldHint annotations, the description adds the METAR vs. TAF distinction, which tells the agent what kind of read data to expect. It doesn't discuss pagination or response size, but the schema already covers those. No contradiction with 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?

A single sentence that front-loads the action and resource, then adds the two relevant data types. Every word earns its place with zero fluff or 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?

The tool is simple: one required parameter, full schema documentation, and read-only annotations. The description covers the key output types and the schema handles the rest. There is no missing information that would prevent a correct call.

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% — every parameter, including 'report', 'cursor', and 'max_pages', has a detailed description. The tool description's mention of METAR/TAF mirrors the 'report' enum but adds no new syntactic or semantic insight, so a baseline 3 is appropriate.

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 uses a specific verb ('Get'), a clear resource ('weather for an airport'), and names the two supported report types (METAR observations and TAF forecast). This sharply distinguishes it from sibling airport tools like fa_get_airport or fa_get_airport_delays.

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 clearly frames the tool's context: it is the go-to for airport weather. It doesn't explicitly name alternatives or exclusions, but no sibling tool provides weather data, so this is sufficient. The METAR/TAF clause hints at when to switch the 'report' parameter.

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?

The description adds a concrete behavioral fact beyond the readOnlyHint/openWorldHint annotations: the tool requires Standard or Premium tier and fails with 401 on the free tier. This is useful operational context. It does not contradict any annotation, and no read/write confusion exists since 'Get' aligns with readOnlyHint.

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 one compact sentence plus a terse tier requirement, with no filler. The primary action and resource are front-loaded, and the auth note is a meaningful second sentence.

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 two-parameter read operation, the description plus rich schema coverage is nearly complete. The auth requirement is stated, the response is implied as the alert object, and annotations already cover read-only/open-world behavior. It only stops short of 5 because it does not explicitly mention not-found behavior or describe the response shape outside the view parameter text.

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 id and view are already documented in the schema. The description itself only repeats 'by its id' and does not add new parameter-level semantics, so the schema-covered baseline of 3 is appropriate.

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 uses a specific verb ('Get') with a clear resource ('a single configured flight alert') and the retrieval key ('by its id'). This cleanly distinguishes it from alert-list, create, update, and delete siblings without requiring schema inspection.

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 implies the right time to use it: when you need one specific alert by id. It also adds an important real-world prerequisite by stating the required AeroAPI tier and the 401 on the free Personal tier. It does not explicitly name fa_list_alerts for listing multiple alerts, but the single-by-id wording makes the selection 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?

Annotations already mark readOnlyHint=true and openWorldHint=true. The description adds a meaningful behavioral disclosure: the tier requirement and the specific 401 error for free tier users. This goes beyond the annotations and helps the agent anticipate failure modes. No contradiction with 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 two sentences with no filler. The purpose is front-loaded, followed by the critical prerequisite. Every word earns its place, and the structure is clean 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?

For a simple getter with one optional parameter, the description covers the core purpose and a key prerequisite. The lack of an output schema is not a major gap because the response shape (the endpoint URL) is implicitly understood. It could note that the response is the endpoint string, but the current level is adequate for correct invocation.

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 itself contains a detailed description of the 'view' parameter, including the compact/full distinction and the rationale for dropping fields. The tool description adds no additional parameter information, so it does not exceed the baseline for fully covered 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 verb 'Get' and the resource 'current delivery (webhook) endpoint' for AeroAPI alerts. It is distinct from sibling tools like fa_set_alerts_endpoint (set) and fa_list_alerts (list alerts), leaving no ambiguity about what this tool retrieves.

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 the key prerequisite (Standard/Premium tier) and the consequence of not having it (401), which informs when the tool can be used. It does not explicitly contrast with alternatives like fa_set_alerts_endpoint, but the retrieval-versus-set purpose is clear from the name and description, so the usage context is effectively communicated.

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=true and openWorldHint=true, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: the explicit tier requirement and the 401 failure mode on the free tier, plus the scoping statement about the recent window. It does not describe paging or rate behavior, but the schema documents cursor and max_pages, so the added transparency is strong.

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 no filler. The primary action and scoping come first, followed by a critical prerequisite warning. Every sentence earns its place and the structure is ideal for quick agent consumption.

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 7 parameters, a clear scoping statement, and a precise tier requirement, the description plus schema cover what an agent needs to call the tool correctly. There is no output schema, but the return value is self-evident from the name and description. It does not spell out pagination flows, though cursor and max_pages are well described in the schema, so the remaining gap 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?

Schema description coverage is 100%, so the input schema already explains every parameter, including ident_type enums and max_pages cap. The description adds no parameter-level detail beyond restating that ident can be a designator, registration, or fa_flight_id, which is already in the schema. This meets the baseline but does not exceed it.

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 uses the specific verb 'Get' with a clear resource, 'historical flights for an ident', and scopes it as 'beyond the recent window covered by fa_get_flights'. This directly distinguishes it from the sibling fa_get_flights while also listing the accepted ident formats. An agent can tell exactly what this tool does and how it relates to the nearest alternative.

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 names the sibling fa_get_flights as the tool covering the recent window, indicating this tool is for older data. It also provides a concrete eligibility condition: requires Standard or Premium AeroAPI tier, while the free Personal tier returns 401. This gives clear when-to-use and when-not-to-use guidance alongside an accessible alternative.

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?

The description discloses a meaningful side effect: the tool writes a PNG to disk and returns a path, unless inline:true returns base64. This adds behavioral context beyond the neutral annotations (readOnlyHint false, idempotentHint false) and helps the agent understand the operation's impact.

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 two sentences with no filler. The primary action, output mode, and disk-writing side effect are front-loaded and clearly communicated.

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 no output schema and annotations that don't describe behavior, the description covers the essential context: what it returns (path or base64), where it writes, and how to request inline output. It doesn't specify exact return type or file overwrite behavior, but those are minor gaps for this 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 description coverage is 100%, so the baseline is 3. The description largely restates what the schema already says for inline and output_dir, and it adds no new meaning for width, height, or show_data_block. It provides no parameter-level detail beyond the 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 opens with a specific verb/resource pairing: 'Get a rendered map image (PNG) of a flight by fa_flight_id.' This clearly differentiates the tool from sibling flight-data tools like fa_get_flight_route or fa_get_flight_track, which return data rather than a rendered image.

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 purpose itself implies when to use it—when a visual map image is needed rather than structured flight data—but the description does not explicitly compare it to alternatives or state when not to use it. There is no mention of sibling tools or exclusion conditions.

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 mark the operation read-only, so the description's job is light. It usefully adds that the result is the 'most recent reported' position and only for 'in-air' flights, but it does not say what happens when no position exists or describe response shaping beyond the 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?

A single front-loaded sentence with no filler. Every word contributes the action, target, scope, and key, making it easy to scan and parse.

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 read-only lookup with one required parameter, rich schema coverage for the optional view parameter, and readOnly/openWorld annotations, the description is sufficient. An agent can correctly invoke it without missing critical context.

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 both parameters, including the compact/full view behavior. The description adds no parameter semantics beyond restating that the identifier is the fa_flight_id, which is already in the 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 opens with the specific verb 'Get' and names a precise resource: 'the most recent reported position for an in-air flight,' keyed by 'fa_flight_id.' This scoping distinguishes it from sibling list/track/route/history tools such as fa_get_flight_track and fa_search_flight_positions.

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 conveys when to use this tool: when a caller needs the latest reported position of an airborne flight. It stops short of explicitly naming alternatives or exclusions (e.g., not for historical tracks), so it does not earn the top score.

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=true and openWorldHint=true, so the safety profile is known. The description adds the term 'decoded' which implies a transformation from raw track data to waypoints, but does not disclose other behaviors such as response size, error conditions, or whether the route is complete. It adds a small amount of context beyond the annotations but not much.

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 sentence that is front-loaded with the core action and resource, with no extraneous words. It is appropriately concise for a simple getter 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?

Given the tool's simplicity (two parameters, one required, no output schema), the description is sufficient for an agent to call it correctly. It specifies the identifier and clarifies the result is a decoded route of fixes/waypoints. The openWorldHint annotation signals unknown fields, so the lack of a detailed output specification is acceptable. However, a brief note on the expected response structure could further aid agents, but it is not critical.

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 fully documents both parameters (id and view) including the detailed explanation of the view enum's compact/full distinction. The description adds no parameter-level information beyond what the schema already provides, meeting the baseline expectation for tools with full 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 a specific verb ('Get') and resource ('decoded route (fixes/waypoints)') tied to a specific flight via fa_flight_id. This distinguishes it from sibling tools like fa_get_flight_track or fa_get_flight_position, which address different aspects of flight data.

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 no guidance on when to use this tool versus alternatives. It does not mention when a route (fixes/waypoints) is preferred over a track, position, or history, nor does it name any exclusions or fallback tools. An agent must infer usage solely from the term 'decoded route', which is implicit.

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 provide readOnlyHint=true and openWorldHint=true, so those aspects are covered. The description adds little behavioral context: it does not mention pagination, rate limiting, or that this tool returns a list of flights rather than a single flight. It only restates the purpose and output, which is minimal beyond the 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 entire description is a single, well-structured sentence that front-loads the purpose and immediately clarifies the identifier types. There is no filler or redundancy, making it highly concise and 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 the complexity (7 parameters) and the presence of many sibling tools, the description is terse. It does not explain how this tool differs from related tools like fa_get_flight_history or fa_get_scheduled_flights, nor does it clarify the return format (list vs single flight). The schema and annotations cover safety and basic behavior, but the description could be more complete in routing agents to the correct tool among many similar ones.

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 schema has 100% description coverage for all 7 parameters, including detailed explanations of ident, view, max_pages, and cursors. The description only reiterates that ident can be a designator, registration, or fa_flight_id, which is already in the schema. No additional semantic value is added for parameter usage beyond what the schema provides.

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 specifies the verb 'Get' and resource 'flights', and explains that 'ident' can be a flight designator, registration, or fa_flight_id. It distinguishes this as a direct lookup by identifier, not a search. It also states the returned flight types (recent, current, scheduled). However, it does not explicitly differentiate it from sibling tools like fa_get_flight_history or fa_get_scheduled_flights, which might also return flights but with different scopes.

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 implies usage when you have an ident and need flights for it, but it does not explicitly state when to use this tool over alternatives. There are no exclusions or references to sibling tools. The requirement to pick between related tools like fa_get_flight_track or fa_get_scheduled_flights is left entirely to inference.

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?

The description is consistent with annotations (readOnlyHint=true, openWorldHint=true) since it describes a 'Get' operation. It adds minor context by calling it a 'breadcrumb log,' implying a sequence of positions. However, it doesn't disclose response ordering, limits, or error behavior. Given the annotations already cover read-only and open-world semantics, this is adequate but not enriched.

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 a single sentence that front-loads the core purpose with no filler. Every word adds value, and it avoids redundancy with the schema or annotations. This is a model of concise specification.

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 tool with three parameters (one required), an enum, and no output schema, the description gives a clear purpose but lacks details about the response format (e.g., array of positions, ordering). Since there is no output schema, the description could have mentioned the structure of the track to aid the agent. The schema covers parameters well, but the response shape is left to inference.

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%, with each parameter (id, view, include_estimated_positions) having detailed descriptions, including the nuanced explanation of 'view' modes. The tool description itself adds no parameter-level meaning beyond what the schema already provides, so the baseline of 3 is appropriate.

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 states a specific verb (Get), a specific resource (position track/breadcrumb log), and the key identifier (fa_flight_id). It clearly differentiates from sibling tools like fa_get_flight_position (single position) and fa_get_flight_route (route) by focusing on the breadcrumb track. An agent can immediately understand what this tool does.

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 no guidance on when to use this tool versus its siblings, such as fa_get_flight_position or fa_get_flight_route. It doesn't mention alternatives, exclusions, or context (e.g., 'use this for historical position history'). The agent must infer usage from the name and description alone.

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 provide readOnlyHint=true and openWorldHint=true, covering safety and exhaustiveness; the description adds no contradictory behavior and its 'find' wording is compatible. It adds no additional behavioral context such as paging or rate limits, but with annotations present the burdon is low.

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?

One sentence, no wasted words, front-loaded verb and resource. Unit conversion (statute miles) is embedded compactly without repeating the schema.

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 supplies the core query semantics needed to select the tool, and the rich schema covers all seven parameters plus response-shape via the view parameter. No output schema exists, but the description and view docs together allude to a list of airports, so no critical call-invocation information is missing.

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 description adds no parameter detail beyond what the schema already gives; it reiterates 'statute miles', which appears in the radius parameter description. Baseline 3 is appropriate because the schema carries the parameter meaning.

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 ('Find') and resource ('airports') with clear spatial modifiers 'near a latitude/longitude within a radius'. It clearly distinguishes its scope from single-airport tools like fa_get_airport by the coordinate+radius criteria, though it doesn't explicitly name any sibling.

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 implies use when you need airports by proximity to coordinates and omits any explicit alternatives or exclusions. It doesn't help an agent choose between this and fa_list_airports or fa_get_airport when boundary conditions overlap.

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=true and openWorldHint=true, so the safety profile is covered. The description adds no behavioral disclosure beyond 'Get details'; it does not describe response characteristics, whether the returned data is normalized, or any caveats about open-world fields. No contradiction exists with the 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?

One concise sentence, front-loaded with the verb and resource, followed by a useful parenthetical about code formats. No filler or repetition of schema 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?

For a simple single-operator lookup, the description plus schema is nearly complete: both parameters are documented, annotations cover the read-only nature, and the code format is clarified. It is slightly incomplete because it provides no pointer to sibling operator tools and the lack of an output schema leaves return details unstated, but the core calling intent is well specified.

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 coverage is 100%, so the baseline is 3. The description adds concrete examples ('UAL' vs 'UA') and clarifies that either ICAO or IATA is acceptable, reducing ambiguity for the required id parameter. The view parameter is already fully documented in the schema, so the description does not need to repeat it.

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 uses a specific verb and resource: 'Get details for an operator (airline) by code.' It clearly distinguishes from sibling tools like fa_list_operators, which lists operators, and fa_get_operator_flights, which returns flights for an operator. The ICAO/IATA clarification makes the target resource 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 phrase 'by code' implies the tool should be used when the caller already has an ICAO or IATA code and wants operator details. However, the description does not name alternatives or exclusion conditions, such as using fa_list_operators to enumerate operators or fa_get_operator_flights for flight activity. Usage guidance is therefore mostly implied rather than explicit.

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 provide readOnlyHint=true, and the description's 'Get' is consistent with that. The description does not add behavioral detail like pagination behavior, rate limits, or response-size caveats, but those are not necessary to correct for the read-only annotation. It adds board enumeration as domain scope rather than novel behavioral 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?

One sentence, front-loaded with the key scoping concept ('operator'), and every word earns its place. It avoids repeating schema details while still conveying the tool's 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 one-line description plus a rich 100%-coverage schema suffices for correct selection and invocation: the required id, board enum, view behavior, and pagination are all documented. There is no output schema, so a brief note about return shape could have helped, but the tool is a straightforward read-only board query and nothing critical is missing.

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%, so the structured definitions already document every parameter. The description's 'arrivals/departures/enroute/scheduled' merely echoes the board enum, and 'operator (airline)' restates what the id schema already says. The description adds no meaningful semantic value beyond the schema, 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?

Description names a specific verb ('Get'), a resource ('flight board for an operator/airline'), and the board variants ('arrivals/departures/enroute/scheduled'). This clearly distinguishes it from sibling tools that cover flights, airports, tracks, or aircraft by making the operator scoping explicit.

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 phrase 'for an operator (airline)' gives clear selection context, separating this tool from fa_get_airport_flights and fa_get_flights. It does not explicitly name alternatives or exclusion conditions, so it falls short of a 5, but the intended use case is 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, and the description adds no extra behavioral context such as pagination semantics, default page limits, billing implications, or handling of codeshares. With no output schema, some disclosure beyond the annotation would be valuable; the description does not contradict the annotations, but it also does not enrich them.

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 a single, front-loaded sentence that conveys the core operation and filters with no filler. It is appropriately sized for the tool's straightforward nature.

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 10-parameter tool with no output schema, the description is somewhat thin and does not mention response shape, pagination, or default behavior. However, the input schema is rich and the read-only annotation covers safety, so the description is minimally adequate for a first call.

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 baseline is 3. The description mentions the main filter parameters (origin, destination, airline, flight number) but adds no meaning beyond what the input schema's per-parameter descriptions already provide.

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 states a specific verb ('Get') and resource ('airline-scheduled flights between two dates') and names the available filters, which clearly distinguishes it from sibling flight-position/track tools. The date-range and filter scope make the tool's 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 implies the intended use case through the wording 'airline-scheduled flights between two dates' but does not explicitly state when to prefer this tool over alternatives like fa_get_flights or fa_search_flights, nor does it provide any exclusion conditions. It gives usable context but no comparative 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?

Annotations already mark it read-only and idempotent, but the description adds meaningful behavioral detail: it resolves the credential the same way real tools do, makes exactly one authenticated request, reports the credential source, round-trip time, and a plain-English failure hint, and never returns the credential itself. This goes well beyond the 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 compact yet information-dense, with the core behavior front-loaded and every sentence contributing either the action, the output details, the safety guarantee, or the usage trigger. No filler or redundant restatement of the title 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?

With no output schema, the description fully explains what the tool reports: credential source, acceptance status, round-trip time, and a hint distinguishing failure modes. It also covers safety (read-only, no credential leakage) and the intended use case, making it complete for an 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?

The tool has zero parameters and the schema is empty, so there is no parameter ambiguity. Per the baseline for 0-parameter tools, the description does not need to compensate for missing schema information, and it appropriately focuses on behavior and output instead.

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 states a specific diagnostic purpose: resolving credentials, making one authenticated request to aeroapi.flightaware.com, and reporting whether the credential was accepted. It clearly distinguishes this healthcheck tool from the many data-fetching siblings by focusing on connectivity and credential validation rather than flight/airport data.

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 gives an explicit trigger: 'Call this when a real tool fails and you want to know which hop broke.' This tells an agent exactly when to use the tool and frames it as a diagnostic aid rather than a data source, which is sufficient given no sibling serves the same role.

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=true and openWorldHint=true, so the safety profile is covered. The description adds the paging behavior explicitly and points to the cursor mechanism, which is useful context, but it does not describe the response shape, links structure, or operational constraints; billing details appear only in the 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?

Two short sentences with the action and resource front-loaded, followed by the one essential usage mechanis. No filler or redundant elaboration; the description is appropriately sized for the tool's complexity.

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?

This is a low-complexity list tool with strong annotations and a fully described schema. The description covers the core enumeration purpose and paging workflow, while the schema handles view semantics and page limiting. A note about output structure would be nice, but 'List airports' sufficiently communicates the return expectation.

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%, with detailed descriptions for view, cursor, and max_pages, including the per-page billing caveat. The description adds no parameter-level semantics beyond repeating the cursor paging instruction, 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 states a specific verb and resource: 'List airports known to AeroAPI', and adds the paging trait, so an agent immediately knows this is a catalog enumeration tool. It is clearly distinct from siblings like fa_get_airport or fa_resolve_airport, which target individual airports.

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 phrase 'List airports known to AeroAPI' implies the tool is for enumerating the full airport catalog, and the direct paging instruction tells the agent how to navigate results. However, it does not name alternatives or provide exclusions, so the agent must infer when to choose this over sibling airport lookup tools.

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=true, so the read-only nature is covered. The description adds a key behavioral trait: the free tier returns 401, which is critical for the agent to know. However, it does not disclose pagination behavior (cursor usage) or that the response is a list, though the schema hints at it. Given annotations, this extra tier detail raises the score above baseline.

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 a single, concise sentence that front-loads the primary action and then provides the crucial tier requirement. Every word earns its place; there is no filler or 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?

For a list operation with optional parameters and no output schema, the description sufficiently conveys the core function and a key prerequisite. It does not explicitly state that it returns all alerts or that pagination is supported via cursor, but these are implied by the schema and the verb 'list'. The description is adequate for an agent to decide to call 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?

Schema description coverage is 100%, so all three parameters (view, cursor, max_pages) are fully documented in the schema. The tool description adds no extra parameter-specific information, so it meets the baseline for high coverage without contributing additional semantics.

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 action ('List') and the resource ('flight alerts') scoped to the user's account. It distinguishes itself from sibling tools like fa_get_alert (which likely retrieves a single alert) by the verb 'list' and by mentioning the account-wide scope. The tier requirement adds useful context without confusing 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 mentions a prerequisite (AeroAPI tier) but does not explicitly contrast with alternatives such as fa_get_alert or the alert CRUD tools. An agent would have to infer that 'list' means all alerts and that fa_get_alert is for a specific one. There is no explicit 'when to use' guidance, though the tier warning provides some usage 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?

Annotations already declare readOnlyHint and openWorldHint, so the description does not need to restate safety. It adds value by explicitly calling out paged behavior and instructing cursor-based navigation, which goes beyond what the annotations provide. No contradiction with 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?

Two short sentences front-load the core action and scope, followed by a single actionable paging instruction. There is no filler, redundancy, or unnecessary repetition of schema 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 no output schema, the description still communicates the resource ('operators'), the domain scope ('AeroAPI'), and the paging mechanism. It could more explicitly describe the return shape as a paged collection, but 'List operators (paged)' plus the cursor instruction makes that reasonably inferable.

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 schema already documents all three parameters in detail, including the view variants, cursor origin, and max_pages billing cap. The description's cursor mention adds no semantic meaning beyond the schema, so it sits at 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 states a specific action ('List'), a clear resource ('operators (airlines)'), and a scope ('known to AeroAPI'). It also signals that the operation is paged, which helps an agent distinguish it from single-operator tools like fa_get_operator.

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 gives clear context: use this tool to enumerate airlines known to AeroAPI, with pagination handled via a cursor. However, it does not explicitly name alternatives or state when not to use this tool, so it stops short of 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 readOnlyHint=true and openWorldHint=true already in annotations, the safety profile is covered. The description adds genuine behavioral context beyond that: the tier requirement and the specific 401 failure mode, informing an agent that a 401 is an expected eligibility outcome rather than a tool malfunction. This is a meaningful disclosure for a tool with auth-dependent 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?

Two sentences with zero filler: the core function is front-loaded, and the operational constraint follows as a clearly marked NOTE. Every word earns its place; the structure makes the key facts instantly 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?

For a simple 3-param, 1-required resolution tool with fully documented params and read-only annotations, the description covers purpose and the key failure mode. The main gap is that 'equivalents' is undefined and there is no output schema, leaving the response shape underspecified for an agent trying to interpret the result. openWorldHint() mitigates this somewhat.

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%: id, view, and id_type each carry descriptive schema text, including enum meanings and the compact/full response-shape difference. The description itself contributes no parameter details, so the baseline 3 applies — 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?

The description uses a specific verb ('Resolve') with a specific resource ('airport code') and a concrete outcome ('canonical AeroAPI identifier (and equivalents)'). This clearly differentiates it from sibling lookups like fa_get_airport or fa_resolve_flight, which operate on different resources. The scope is unambiguous even before inspecting 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?

There is no guidance on when to choose this tool over siblings — e.g., use fa_get_airport when the ID is already canonical, or fa_resolve_flignt for flight identifiers. The only usage-relevant note is the AeroAPI tier eligibility (Standard/Premium required, free tier returns 401), which is an operational constraint rather than an alternative-routing rule. An agent must infer selection criteria from the name alone.

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 convey read-only behavior, and the description adds a concrete behavioral constraint: the free Personal tier returns 401 and Standard/Premium is required. This goes beyond the structured metadata and helps an agent anticipate failure.

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 no filler: the functional purpose is front-loaded, and the auth caveat is placed second where it is easy to notice. Every sentence earns its place.

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 single-required-parameter resolver, the definition is nearly complete: the schema documents all params, annotations cover safety, and the description states the output's nature and a key auth requirement. The absence of an output schema is partially mitigated by the description, though response details remain unspecified.

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%, with clear meanings for ident, ident_type, and view. The description adds no parameter-specific detail beyond what the schema already provides, which is acceptable at 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 names a specific verb ('Resolve'), a precise resource ('flight ident' as designator/registration), and the expected outcome ('canonical form and any alternate idents'). It also differentiates from sibling fa_resolve_airport by constraining the resource type.

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 intended use case is clear but only implied: canonicalize a flight ident. The description does not explicitly state when to choose this tool over search/fetch siblings or provide exclusions, so an agent must infer the right 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?

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds 'live' semantics and the return-shape distinction, but does not disclose details like per-page billing or external API interaction beyond what the schema already notes. No contradiction with 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 two focused sentences plus an example, with the action and resource front-loaded. Every clause earns its place, and there is no filler or repetition of schema details.

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?

All four parameters are fully documented in the schema and the description supplies the essential query-grammar context. The main remaining gap is that return values are described only at a high level ('position points'), with no output schema to fill in the shape, but this is still sufficient for correct selection and invocation.

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%, so the baseline is 3. The description adds value by disambiguating the query grammar and reinforcing it with a concrete example, which is especially useful for the structured-language parameter. view, cursor, and max_pages are already well documented in the 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 searches live flight positions and, crucially, says it returns position points rather than flight summaries. This distinguishes it from summary-returning sibling tools like fa_search_flights_advanced even before looking at schemas.

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 gives explicit query-syntax guidance: use the structured {operator key value} grammar, same as fa_search_flights_advanced, and explicitly warns against the simplified '-key value' syntax. It does not enumerate every when-to-use/when-not-to-use case, but the position-points-vs-summaries contrast makes the main selection criterion 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?

Annotations already mark the tool as readOnlyHint and openWorldHint, so the safety profile is covered. The description adds useful behavioral context about the syntax being a single string of "-key value" pairs and lists supported keys, but it does not disclose traits like default result limits, ordering, or how "airborne" is defined. No contradiction with 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 one dense, front-loaded sentence with no filler. It immediately states the action, then gives the syntax, the full key list, and an example. Every part is functional and earns its place despite the list length.

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 four parameters, complete schema descriptions, and readOnly/openWorld annotations, the description is largely sufficient: it explains the query string syntax, lists the keys, and gives an example. The main gap is the lack of output-shape guidance (no output schema) and no explicit relationship to the advanced sibling, but these are not fatal for correct invocation.

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 baseline is 3. The description adds real value by enumerating the accepted query keys and providing a concrete example, which the schema's query property description alone does not explain. This pushes parameter semantics above 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 a specific action and resource: searching airborne flights with a particular query syntax. It is distinguishable from siblings by mentioning the "simplified query syntax," but it does not explicitly call out the difference from fa_search_flights_advanced or fa_get_flights, so it falls short of full sibling differentiation.

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 implies usage through phrases like "simplified query syntax" and the airborne-flights scope, but it never specifies when to prefer this tool over fa_search_flights_advanced, fa_get_flights, or other flight-search siblings. There is no explicit when/when-not guidance or alternative routing.

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 and openWorldHint, so the safety profile is covered. The description adds meaningful behavioral context by explaining how the query is parsed as space-separated predicates, listing the supported operators, and giving example syntax—this goes well beyond the structured 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?

Dense but efficient: it front-loads the purpose, then packs the query syntax, operators, example, and common keys into a compact set of clauses. Every part earns its place given the tool's complexity.

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 read-only search tool with four parameters, the description plus rich schema provides everything needed: the query predicate language, operators, keys, example, and schema explanations for view/cursor/max_pages. No obvious required usage detail is missing.

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%, so the schema already documents all parameters. The description adds real value beyond that by explaining the query format, operator semantics, common keys, and ICAO code conventions, which the schema only sketches.

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 ("Search flights") and immediately distinguishes itself from the sibling fa_search_flights by calling it more expressive. The query-language detail makes it unmistakable what this tool does.

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 implies when to use this tool by comparing it to fa_search_flights (more expressive), giving a clear reason to choose it over the simpler sibling. It does not explicitly state when-not-to-use it or name other alternatives, but the contrast is 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?

Goes well beyond the annotations (readOnlyHint=false, idempotentHint=true) by disclosing the critical two-step confirmation behavior, that the first call makes NO network request, that a confirmToken is returned and must be reused, and that the free tier returns 401. This is exactly the kind of behavioral nuance an agent needs before invoking a mutating endpoint.

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 dense but not bloated: the main purpose is front-loaded, and the second sentence efficiently covers confirmation, the no-network first phase, token semantics, and tier constraints. Slightly long due to necessary caveats, but every clause carries 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 no output schema, the description compensates by stating what phase-one returns (method, path, body preview plus confirmToken), how to complete the operation, when the two-step flow applies, and the authentication failure mode. An agent has enough information to call the tool correctly in both confirmed and fallback modes.

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 url, format, and confirmToken in detail. The description reinforces the url's purpose and the confirmToken's role, but it adds little semantic meaning beyond the schema—so the baseline 3 is appropriate.

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?

Begins with a specific verb and resource: 'Set the delivery (webhook) endpoint AeroAPI POSTs alert notifications to.' It clearly distinguishes itself from the read-oriented sibling fa_get_alerts_endpoint and from alert CRUD tools like fa_create_alert or fa_update_alert.

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 clear operational context: confirmation-first behavior, the two-step fallback flow, the MCP_CONFIRM_MODE dependency, and the Standard/Premium tier requirement with a 401 on the free tier. It lacks an explicit 'use fa_get_alerts_endpoint instead to read the current endpoint' exclusion, but the context is otherwise unambiguous.

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 carry idempotentHint/openWorldHint/readOnlyHint, and the description adds substantial behavior beyond them: the first call makes NO network call, the preview includes method/path/body, only a repeat call with confirmToken proceeds, and the operation replaces existing configuration. No contradiction with 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?

Three sentences, front-loaded with the core purpose, then the confirmation flow, then the prerequisite. The middle sentence is long but every clause (preview contents, no network call, repeat-with-token) is necessary to prevent misuse.

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 16-parameter mutation with a two-phase confirmation protocol, the description covers purpose, confirmation mechanics, and entitlement. It doesn't describe the final response body on the confirming call, but with no output schema and a clear flow, an agent has enough to invoke it 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%, including a rich explanation of confirmToken semantics in the schema itself, so the description needn't repeat parameter details. The description connects confirmToken to the two-step flow but doesn't add per-parameter meaning beyond the schema, matching the baseline for full 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?

Description opens with 'Update an existing flight alert (replaces its configuration)' – a specific verb and resource that clearly states the operation. It is unmistakably distinct from siblings like fa_create_alert, fa_delete_alert, and fa_list_alerts.

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 provides concrete usage context: the confirmation flow (client prompt vs. preview+confirmToken fallback) and the tier requirement (free Personal tier returns 401). It doesn't explicitly name sibling alternatives or when-not-to-use conditions, but the 'existing' qualifier and detailed flow give solid guidance.

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