Travel Risk API

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile needs no restating. The description adds the useful fact that all arguments are optional with a default limit of 20, but says nothing about result freshness, pagination, or what happens when filters match nothing.

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, purpose first, parameters second, zero filler. The dense argument clause is justified because the schema supplies no descriptions of its own.

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

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

An output schema exists, so return values need not be explained, and all four optional parameters are covered in the description. The only real gap is routing guidance against the nearby advisory and conflict tools, which is a usage-guideline concern rather than missing call mechanics.

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

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

Schema description coverage is 0% and the schema contains no enums, so the description carries the full burden — and it does: country as ISO alpha-3, the four severity values Low|Medium|High|Critical, days as a lookback window, and limit bounded 1-100 with default 20. Every parameter is documented beyond what the bare 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?

Names a specific resource and scope: 'Active natural-disaster and severe-weather alerts', with examples (earthquakes, storms, floods, wildfires) that pin down the domain. An agent can distinguish it from aircraft/flight tools, but there is no explicit differentiation from the closest siblings, travel_advisories and conflict_events.

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 states what the tool returns but never says when to reach for it over travel_advisories or conflict_events, nor any prerequisites or exclusions. Usage must be inferred from the topic 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 declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety and determinism are covered. The description adds genuine behavioral value with 'age where known', signaling that fields can be legitimately absent rather than an error, but it says nothing about coverage, lookup failures, or auth.

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

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

Two sentences, front-loaded with the resource and key, followed by the argument format. No filler, no redundancy with the schema or annotations.

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

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

An output schema exists, so return values need no explanation, and the annotation set covers the safety profile; for a one-parameter lookup the description is nearly sufficient. The only gap is that it never characterizes the sibling alternatives or failure/not-found behavior.

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

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

Schema description coverage is 0%, so the description must carry the single parameter's meaning, and it does: 'registration = tail number' plus two concrete format examples (N12216, F-GSQA) that clarify expected syntax. It stops short of stating whether hyphens are required or accepted, so it is good but not exhaustive.

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 lookup keyed on registration and enumerates the attributes returned (type, manufacturer, operator, age, in-flight Wi-Fi), which is far more than a restatement of the name. It does not explicitly contrast itself with siblings like flight_wifi or airline_wifi, so an agent must infer the boundary.

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?

Usage is only implied: the argument description ('tail number such as N12216 or F-GSQA') hints that this is a lookup by registration. There is no statement of when to prefer this over flight_wifi, airline_wifi, or flight_status, and no exclusions or prerequisites are given.

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, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds the payload contents, but since an output schema exists, that content listing is largely redundant and no other behavioral context (rate limits, freshness, coverage gaps) is offered.

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 compact sentences, front-loaded with the resource and its payload before the argument note. Every clause earns its place, with no filler.

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

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

For a single-parameter read tool with an output schema and full annotation coverage, the description supplies the critical missing piece (accepted code formats) and the data scope. Only the when-to-use routing and edge-case behavior are 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 0% and the lone parameter has no description, so the description carries the full burden — and it does, specifying that 'airline' accepts either IATA (e.g. UA) or ICAO (e.g. UAL) codes with concrete examples. This is exactly the disambiguation an agent needs, though nothing is said about invalid or ambiguous codes.

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 resource (airline profile) and enumerates its contents — identity, fleet, IOSA safety-audit registration, accident history, links — so an agent knows exactly what it returns. It is clearly distinct from sibling lookups like aircraft or airline_wifi, though the differentiation is implicit rather than stated.

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?

No guidance on when to choose this over siblings such as aircraft, airline_wifi, or country_profile, and no preconditions or exclusions. The agent must infer usage from the resource 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 declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful content context (that results are broken down by aircraft type and include Starlink fleet share), but does not address coverage, pagination, or what happens for an unknown/unserved airline code.

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 tight sentences, with the resource and scope front-loaded and the argument semantics appended as a compact clause. No filler or restatement of the tool name.

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

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

With an output schema present, the description need not explain return values, and it correctly focuses on scope and argument format. It is complete enough to invoke correctly; the only gap is sibling differentiation, which is a usage-guidance concern rather than a completeness one.

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

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

Schema description coverage is 0%, so the description carries the full burden for the single parameter, and it does: 'airline = IATA or ICAO code' tells the agent the accepted identifier formats, which is not present anywhere in the schema. It does not say whether both formats are accepted simultaneously or which is preferred.

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 resource (in-flight Wi-Fi) with a clear scope modifier ('of an airline by aircraft type') and enumerates the returned dimensions (system, speed class, free, Starlink share). It does not explicitly name the sibling flight_wifi, so the fleet-level vs per-flight distinction is left implicit rather than contrasted.

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 when-to-use or when-not-to-use guidance and no alternative named, despite flight_wifi and airline_profile being obvious siblings. The agent must infer from 'by aircraft type' that this is a fleet-level lookup rather than a per-flight one.

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 establish read-only, idempotent, non-destructive behavior, so the description is free to add what they cannot: the regional coverage asymmetry between US-centric wait/delay data and worldwide weather. It stops short of disclosing data freshness or what happens when an airport has no waits data, which would be the remaining useful traits.

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

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

Two sentences, front-loaded with what the agent gets, followed by the coverage caveat and the argument format. Every clause carries information and nothing is repeated from the schema or annotations.

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

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

With an output schema present, return values need no explanation, and the description supplies purpose, coverage scope, and the required parameter's format. The only residual gaps are data freshness and behavior when US-specific wait data is unavailable, which are minor for a read-only aggregation 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 0%, so the description carries the burden for the single parameter and does so well, specifying that the airport argument accepts either IATA or ICAO codes with concrete examples (JFK/KJFK). This is exactly the guidance missing from the schema and prevents invalid-format calls.

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-resource pairing (aggregated airport conditions) and enumerates exactly what is returned: delay programs, ground stops, security/immigration waits, weather, forecast, and recent traffic. This enumeration also implicitly separates it from narrower siblings such as airport_security_wait, since an agent can see this tool bundles their content.

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 real selection context by disclosing coverage limits: waits and delay programs are strongest for the US while weather is worldwide, which directly informs whether the tool is worth calling for a given airport. It does not name an alternative sibling (e.g., airport_security_wait for a single wait type) or state explicit exclusions, so it falls 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds value beyond that by disclosing that each returned figure carries measurement provenance and timestamp — useful for an agent deciding whether to trust the numbers — though it does not state coverage gaps, freshness limits, or what happens for unsupported airports.

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 front-loaded sentence capturing resource, granularity, scope, and output provenance, followed by a compact args clause. No filler, no restatement of the title, and the essential scoping information comes first.

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 a single required parameter, a 0%-coverage schema, a declared output schema, and rich read-only annotations, the description supplies nearly everything needed: what it returns, provenance, and the identifier format. The only missing piece is guidance on when to prefer this over the adjacent border_wait or airport_conditions tools.

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

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

Schema coverage is 0% and the schema only declares a bare string, so the description is the sole source of parameter meaning. 'airport = IATA or ICAO code' usefully constrains the accepted identifier format, which the schema does not. It stops short of showing example values or case/format rules (e.g. 'JFK' vs 'KJFK').

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+resource+granularity: security checkpoint wait times, broken down by checkpoint, scoped to an airport. It is clearly distinguishable in substance from the sibling border_wait (security vs. border), but it never names that sibling or explicitly disambiguates itself from it, so differentiation is implicit rather than stated.

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 when-to-use guidance at all: no conditions, no prerequisites, and no routing to alternatives such as border_wait or airport_conditions. The phrase 'with how each figure was measured and when' describes output characteristics rather than usage context, so an agent must infer when this tool is the right pick.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive, so the safety profile is clear. The description adds useful behavioral context like the 300 km radius and 48-hour window, but does not cover potential rate limits, auth requirements, or latency.

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

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

The description is concise: first sentence states purpose, second lists per-segment outputs, third explains flags, fourth details arguments. It is well-structured and front-loaded with the core functionality.

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

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

Given the tool's complexity (multi-segment itinerary assessment) and the sparse schema, the description provides necessary context about what is evaluated and the argument structure. With an output schema present, it need not explain return values, but more guidance on usage vs siblings could improve completeness.

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

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

Schema coverage is 0% and the schema itself is nearly empty (segments as untyped array). The description compensates by detailing the segment object structure (type, flight, from_airport, to_airport, country, city, start, end) and the optional trip_id, adding substantial meaning 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 clearly states it checks a whole itinerary in one call, listing exactly what is returned per segment (country risk score, advisory levels, alerts within 300 km, live flight status). This specific verb+resource distinguishes it from siblings like country_risk or active_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 implies usage by describing what it does and the conditions (e.g., live status for flights departing within 48 hours, alerts within 300 km). However, it does not explicitly name alternatives or when to prefer them over using multiple sibling 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, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety and idempotency profile is covered. The description adds the lane-level granularity of the data, but says nothing about freshness, refresh cadence, or how ports are matched — modest added value.

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

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

Two sentences, front-loaded with the resource and scope, followed by a compact arg hint. No filler or restated noise.

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 one-parameter read tool with an output schema (so return values need not be explained), the description covers purpose, scope, and argument format. The only gap is the absence of usage context relative to siblings and any note on data freshness.

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

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

Schema description coverage is 0%, so the description carries the burden and does so: it names the parameter, explains it accepts either a port name or port number, and gives a concrete example ('San Ysidro'). That materially reduces invocation ambiguity for the single required parameter.

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

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

States a specific resource (land border crossing wait times) with explicit scope (US borders with Canada and Mexico) and granularity (by lane). This cleanly distinguishes it from the sibling airport_security_wait, which covers airports rather than land ports of entry.

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 scope phrase 'US borders with Canada and Mexico' implies when the tool applies, but there is no explicit when-to-use statement, no exclusions, and no named alternative (e.g., airport_security_wait for airports). Usage is inferable but not guided.

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 readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely non-derived behavior: the effective default look-back of 7 days, the effective default of 20 results, and a hard 1-100 bound that the schema (bare integer, no minimum/maximum) does not express. It stops short of noting update cadence, data sources, or that openWorldHint=false despite aggregating external news.

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 of purpose followed by one sentence of argument documentation, with the resource description front-loaded. No filler and no restatement of the name.

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 3 optional parameters all documented, annotations covering the safety profile, and an output schema handling return structure, the definition is sufficient to invoke the tool correctly. Only the sibling-routing question is left open, which affects usage guidance rather than completeness.

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

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

Schema description coverage is 0%, so the description carries the burden and largely does: it gives the format for country (ISO alpha-3), the meaning of days (look-back window) with a default, and both the range and default for limit. It could go further by stating what limit counts (events, not sources) and whether country filtering is exact-match or regional.

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 resource ('recent armed-conflict and political-violence events') and the fields it carries (location, severity, news link). It is clearly distinct from sibling infrastructure tools like aircraft or border_wait, though it never explicitly contrasts itself with the overlapping country_risk, travel_advisories, or active_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?

The description gives argument semantics but no when-to-use guidance: nothing says when to call this instead of country_risk, travel_advisories, or active_alerts, all of which plausibly overlap. No prerequisites, exclusions, or coverage caveats are 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?

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered externally. The description adds useful content context by listing the returned fields (advisory level, summary, active alerts), but says nothing about freshness, caching, or what happens for an unknown country code.

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 payload description front-loaded and the argument format isolated in an 'Args:' clause. The argument note arguably repeats schema territory but earns its place because the schema has zero field documentation. No filler.

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

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

An output schema exists, so return values need not be explained, and the single parameter is fully specified. The gap is routing: with fifteen travel-domain siblings, the description never states how this compares to country_risk or travel_advisories, leaving selection ambiguous.

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

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

Schema description coverage is 0% and the schema only declares 'country' as a bare string, so the description carries the full burden. It does this well by specifying ISO 3166-1 alpha-3, which prevents an agent from passing alpha-2 or a country name. It stops short of giving a concrete example or error behavior, so a 4 rather than a 5.

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 resource (country profile) and enumerates the payload it returns: name, region, advisory level with summary, and active alerts. This clearly signals a read of a composite country record. However, it does not differentiate itself from close siblings like country_risk, travel_advisories, or active_alerts, which appear to overlap in content.

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 when-to-use guidance at all. With siblings such as country_risk, travel_advisories, and active_alerts, an agent cannot tell from this text whether country_profile is a broad overview or a specific slice, nor when it should be preferred over those alternatives.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds the composition of the returned score ('how the score is built'), which is mildly useful behavioral context, but says nothing about freshness, coverage gaps, or auth. Adequate, 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?

One dense sentence listing the return payload, followed by a compact Args clause. Front-loaded with the resource, no filler, and 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?

An output schema exists, so the enumeration of return fields is partly redundant, but the parameter format note closes the only real gap for this single-argument read tool. Nothing an agent needs to invoke it correctly appears to be 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 0% and the schema only says 'Country' as a string, so the description carries the full burden. It supplies the exact format (ISO 3166-1 alpha-3) plus concrete examples (FRA, USA, JPN), which is precisely the information needed to avoid passing 'France' or 'FR'.

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?

Names a specific resource (travel risk for a country) and enumerates the concrete outputs: composite risk score 0-5, advisory level 1-4, and alert counts by severity. It is clearly distinguishable in spirit from country_profile or travel_advisories, but it never names those siblings, so an agent must infer the boundary itself.

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?

Usage is implied by 'travel risk for a country' as opposed to, say, a static profile or a raw alert list, but there is no explicit when-to-use statement and no exclusion pointing to travel_advisories, active_alerts, or country_profile. The agent gets the gist but not the routing rule.

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 readOnly, idempotent, non-destructive and openWorld, so safety behavior is covered. The description adds one genuinely useful behavioral detail beyond them: 'where available' warns that gate/terminal fields may be absent. It says nothing about freshness, caching, or error behavior when a flight number is unknown.

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 lean sentences, front-loaded with the payload of returned fields and followed by the arg format. No filler, no repetition of the tool name.

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

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

An output schema exists, so return values need not be explained, and the one required parameter is fully covered with an example; annotations cover the safety profile. The only shortfall is the absence of any routing context against the large set of sibling aviation tools.

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

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

Schema coverage is 0%, so the description carries the burden, and it does: the single arg is documented as an IATA flight number with a concrete example ('UA1'). Minor ambiguity remains (case sensitivity, whether a date is ever needed for ambiguous flight numbers).

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 resource and enumerates exactly what it returns (departure/arrival airports, scheduled/estimated/actual times, delays, gate, terminal), which clearly separates it from siblings like flight_wifi or aircraft. It stops short of explicitly contrasting itself with those siblings, so it is clear but not self-differentiating.

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 when-to-use guidance, no prerequisites, and no mention of alternatives among the many aviation siblings (flight_wifi, aircraft, airport_conditions). Only the word 'Live' hints that this is for current rather than historical status.

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 readOnly/idempotent/non-destructive, so the bar is lower. The description adds genuinely useful behavioral context: the result is a probability estimate ('Expected', 'probability of Starlink or another system, or none') derived from the aircraft type typically assigned, not a live Wi-Fi status. That heuristic nature is important for interpreting the answer.

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 front-loaded sentences: purpose first, then Args with parameter formats. No filler, though the inline 'Args:' enumeration is slightly terse/telegraphic rather than fully integrated prose.

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

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

An output schema exists, so return values need not be explained, and the annotations cover the safety profile. For a two-parameter read-only lookup, purpose, semantics, and the probabilistic nature of the result are all covered; only sibling differentiation 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 0%, so the description must carry the load, and it does: it documents both parameters, including the IATA format with an example ('UA1') and the date format ('optional YYYY-MM-DD'). It does not say what happens when date is omitted (default/today) or which flight instance the date selects, leaving a small gap.

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+resource ('Expected in-flight Wi-Fi for a flight') and scopes it to the aircraft usually flying the route. It is clear what the tool returns, but it never distinguishes itself from the sibling airline_wifi, which an agent could easily confuse with this flight-level tool.

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

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

Usage is only implied: you supply a flight number to get Wi-Fi expectations for that flight. There is no explicit when-to-use, when-not-to-use, or pointer to airline_wifi as the airline-level alternative, which is the most likely selection ambiguity for this agent.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered by structured data. The description adds one genuinely useful behavioral caveat — results are 'approximate' — but says nothing about rate limits, lookup latency, or accuracy variance across countries.

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-loaded with the outcome and scope before the argument note. Every clause carries information; nothing is padded or repeated from 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?

An output schema exists, so the description needn't enumerate the return shape, and the annotations cover the read-only, idempotent nature of the call. For a single-argument read tool this is complete enough to invoke correctly without opening the schema.

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

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

Schema description coverage is 0% and the single 'ip' property carries no title-level documentation, so the description does the work by specifying 'IPv4 or IPv6', which is the main format ambiguity the agent faces. It stops short of noting accepted formats (CIDR, hostnames, leading zeros) or the required/optional status, but compensates well for a one-parameter tool.

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 resource (a public IP address) and the exact result set (country, region, city, coordinates), so the agent knows precisely what comes back. It is clearly distinct from every sibling, all of which are travel/flight/country oriented.

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?

Usage is only implied: the word 'public' silently tells the agent not to pass private/reserved addresses, but there is no explicit when-to-use statement, no note on what happens for private or invalid IPs, and no referenced alternative within the sibling set.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds that results are aggregated from multiple governments and normalised to a 1-4 scale with summary and link, but says nothing about coverage gaps (countries without advisories), freshness, or auth/rate constraints. With annotations carrying the safety burden, a 3 is appropriate.

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: the capability and result shape front-loaded, then a terse args clause. No filler, no repetition of the tool name, and the most load-bearing detail (ISO alpha-3) is stated compactly.

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

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

An output schema exists, so return-value explanation is not required, and the description covers purpose, sources, normalisation and both arguments. The gap is the absence of any routing guidance against close siblings (country_risk, conflict_events) and no note on countries that may lack advisories.

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

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

Schema description coverage is 0%, so the description carries the entire burden, and it does: country is specified as an ISO alpha-3 code (a critical format detail the schema omits entirely) and min_level as an optional 1-4 filter. Both parameters are fully characterised despite the empty schema titles.

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 resource (official travel advisories) and its provenance (several governments, e.g. US, UK, Canada, Australia), plus the normalisation scheme to a 1-4 level. This is clearly separable from adjacent siblings like country_risk and conflict_events, which surface different 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?

Usage is implied rather than stated: an agent can infer this is the tool for government advisory levels, and the min_level filter hints at narrowing behaviour. However, there is no explicit when-to-use guidance or contrast with siblings such as country_risk, so the agent must infer the boundary itself.

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