SeatWiFi

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

readOnlyHint and openWorldHint already cover the safety profile, so the description only needs to add context. It does disclose the return composition (providers, fleet summary, free-WiFi boolean), but says nothing about coverage gaps, freshness, or what happens for airlines with no data.

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 return contents first and the usage discriminator second. No filler, no repetition of the title.

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 carries the burden of describing returns, and it does so at a high level (providers, summary, free WiFi). For a single-parameter read tool that is close to sufficient, though the shape of the 'fleet summary' remains vague.

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?

One parameter with 100% schema description coverage (IATA code with UA/DL examples), so the schema does all the work. The description adds nothing about airline_code format or case sensitivity, which is an acceptable baseline case.

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 the specific resource (WiFi providers an airline uses fleet-wide) and enumerates the payload shape: fleet summary plus a free-WiFi flag. It also scopes itself against flight-level lookups by saying 'about the airline rather than one flight,' though it never names get_flight_wifi directly.

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?

"Use when the question is about the airline rather than one flight" gives a clear selection rule and implicitly routes flight-specific queries to get_flight_wifi. No explicit exclusions or prerequisite conditions are stated, but the discriminating condition is present.

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 the return shape (answer line, confidence, last_observed, basis) and, importantly, that the dated tail prediction is omitted — a real behavioral difference from the sibling. It stops short of saying how stale data can get or whether the underlying answer can disagree with get_wifi_facts, which would complete the picture.

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

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

Front-loaded with the identity of the tool and its alternative, and every sentence carries information. The closing 'Otherwise use get_wifi_facts' mildly restates the routing rule already implied earlier, a small redundancy that keeps it off a 5.

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-only alias with no output schema, the description covers purpose, the routing decision, and the returned fields, including what is deliberately missing versus the sibling. Nothing an agent needs to call it correctly is absent.

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

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

Schema coverage is 100% and the single parameter is documented with examples, so the baseline is met; the description still adds value by stating there is no date argument, which is the key semantic contrast with get_wifi_facts. It does not add further format or validation detail.

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 — a compatibility alias of get_wifi_facts that returns a WiFi answer line for a flight number — and explicitly scopes it to the no-date case. An agent can distinguish it from get_wifi_facts and the other siblings without opening the schema.

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

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

Gives an explicit trigger (user wants a quick WiFi answer) plus an explicit precondition (get_wifi_facts not available) and names the default alternative when that precondition fails. Nothing is left 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=true and openWorldHint=true, so the safety and openness profile is covered. The description adds value by enumerating the possible status values (complete, in_progress, planned, announced), which tells the agent what vocabulary to expect in results. It says nothing about data freshness or whether a missing airline yields an empty set or an error.

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?

Content is compressed into two clauses with no filler, and the returned data shape is front-loaded ahead of the parameter note. It is dense to the point of reading as a fragment, but nothing 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?

With no output schema, the description correctly compensates by listing what is returned (status, fleet percentage, expected completion). For a single optional filter this is nearly sufficient; the only real gap is the absence of any routing cue to the airline- or flight-level WiFi siblings.

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

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

Schema coverage is 100% and the schema already documents airline_code as an optional IATA filter with an example. The description goes one step beyond by stating the semantics of omission — no filter returns all tracked airlines — which the schema does not spell out. Only one parameter exists, so this is close to 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?

The description names the specific resource (Starlink and satellite WiFi rollout progress per aircraft type) and enumerates the returned facets: status, fleet percentage, expected completion. It does not differentiate itself from close siblings like get_airline_wifi or get_wifi_facts, so an agent must infer whether rollout data lives here or there.

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 clause 'Omit airline_code for every tracked airline' gives real guidance on the optional filter's default behavior, which is the main decision an agent faces. However, there is no statement of when to prefer this tool over get_airline_wifi or get_speed_stats, so sibling selection is left 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 cover safety (readOnlyHint) and open-world reach, so the description correctly spends its words elsewhere: it discloses that the data is crowd-sourced (implying sparse/uneven coverage) and that combining the two identifiers is invalid. It stops short of saying what is returned when no reports exist for a route or which key wins if both are supplied.

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 short sentences: what the data is, when to use it, how to call it. Front-loaded and every clause carries information; nothing is redundant with the title.

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 usefully names the return contents, which is the key gap-filler. One hole remains: both parameters are optional (0 required), but the description only says to pass one — it never states the behavior or default when neither is given.

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 both parameters are already documented with examples at the schema level. The description's "not both" mutual-exclusion rule is a genuine addition the schema does not encode, but it adds no format or scoping detail beyond that single constraint.

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?

Specific verb+resource: crowd-sourced in-flight WiFi speed reports, enumerating the returned metrics (download/upload Mbps, latency, per-provider breakdown). This implicitly separates it from siblings like get_wifi_facts or get_flight_wifi, but no sibling is named, so an agent comparing get_flight_wifi vs get_speed_stats must still 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?

"Use for 'is the WiFi fast enough' questions" gives a concrete triggering intent, and the closing constraint specifies the invocation rule. It does not mention when to prefer a sibling tool instead, so the alternative-selection guidance is implied 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 safety profile is covered externally. The description adds the nature of the data (provider history, crowd-sourced reports), which hints at reliability, but says nothing about freshness, coverage gaps, or what happens for unknown tails.

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 zero waste; the resource and scope come first and the usage cue follows. Nothing to trim.

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 no output schema, the description adequately conveys what data comes back and when to reach for it. Minor gaps remain around result shape and behavior for unrecognized tail numbers.

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

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

With one parameter at 100% schema coverage, including an example format, the schema already carries the semantics. The description's "by tail number" restates rather than extends that, so baseline 3 applies.

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

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

States a specific verb+resource: WiFi provider history for one aircraft by tail number, plus the content returned (crowd-sourced reports, fleet assignment). This is clearly distinguishable from siblings like get_flight_wifi or get_airline_wifi, though it never names them directly.

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?

"Use when the exact airframe is known" gives a clear triggering condition that implicitly contrasts with flight-level or airline-level lookups. It stops short of naming alternatives or stating when not to use it.

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

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

Annotations already cover read-only and open-world behavior, and the description adds substantial context: the 60-day verification window, the confidence scale (high/medium/low/none), the basis field values, and the prediction of provider/tail for the date. It does not say what happens for an unknown or unsupported flight number, which is the main remaining behavioral gap.

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

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

Front-loaded with 'Use when...' so the trigger is immediately visible, and the return-field enumeration is dense but justified since there is no output schema. The long run-on field list is slightly heavy but no sentence is filler.

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

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

With no output schema, the description correctly compensates by naming the returned fields and their semantics (answer line, Starlink share, confidence levels, basis, tails, prediction). Only the failure/empty-data behavior for an unmatched flight number is left unaddressed.

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 both the flight_number format variants and the YYYY-MM-DD date default are already documented in the schema. The description only echoes that a date drives the prediction and that input is a flight number, adding little syntax or edge-case meaning beyond the schema; 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?

Names a specific verb+resource (facts about WiFi/Starlink on a specific flight) and enumerates the exact questions it answers: WiFi presence, Starlink odds, provider, aircraft. The closing line 'Always the first choice for a flight number' explicitly separates it from siblings like get_flight_wifi and get_airline_wifi.

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?

'Use when the user asks whether a specific flight will have WiFi or Starlink... or the odds of Starlink on a flight number' gives a clear triggering condition, and the final sentence establishes precedence. It never names the alternative tools to use for non-flight-number phrasing (airline-level or search), so the routing is one-sided rather than fully comparative.

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 genuinely new context with the 'large response' warning, which tells the agent this call is expensive to pull into context. It does not say whether results are paginated or how many airlines to expect, leaving a minor gap.

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, both front-loaded with the decisive information: what it returns first, then the size caveat and alternatives. Nothing is repeated from the title or schema and no sentence is 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 zero-parameter enumeration tool with no output schema, the description covers the return shape ('with its WiFi providers'), the operational cost, and the alternatives. There is nothing else an agent needs before calling 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?

Zero parameters and 100% schema coverage, which is the baseline-4 case. The description appropriately spends no words on parameters and instead uses the space for routing and response-size guidance.

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 exactly what is returned: every airline tracked, paired with its WiFi providers. It explicitly distinguishes itself from siblings search_wifi and get_airline_wifi by naming them, so an agent can tell which tool enumerates the full corpus vs. which fetches a specific record.

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

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

Gives explicit when-not-to-use guidance: use search_wifi or get_airline_wifi when the target airline is already known. Combined with the 'large response' warning, the agent has both the routing rule and the cost signal needed to choose correctly.

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 safety and network scope are covered. The description adds that this opens a view (as opposed to returning a data record) and lists its contents, but says nothing about what is actually returned or whether this launches a UI a follow-up call depends on.

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 verb and resource, with the content list earning its place for routing. The trailing "Takes no arguments" is redundant against an empty schema and could be dropped.

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 no-argument navigation tool this is close to adequate, and annotations carry the safety profile. But with no output schema, the description never says what calling it yields (rendered view vs structured payload) or what the agent should do next, leaving a real gap for a UI-opening 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?

Zero parameters, so the baseline is 4. The sentence "Takes no arguments" merely restates the empty schema and adds no semantic value, but nothing is missing.

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 ("Opens the SeatWiFi home view") and enumerates what that view contains: search, Starlink/satellite rollouts, tracked airlines. That distinguishes it from the narrower siblings like get_rollouts or list_airlines, though it never explicitly says it is the entry/overview point.

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 word "home view" implies an entry point, but there is no explicit statement of when to call this versus search_wifi or the get_* siblings. An agent must infer the routing from the enumerated contents 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 readOnlyHint and openWorldHint annotations already establish the safety and open-world profile. The description adds the important scoping constraint that this is a broad free-text search for partial information, but it does not describe matching behavior, result ordering, or result limits.

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

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

Two sentences, both front-loaded with actionable routing information. Every clause earns its place by either defining the search scope or directing the agent to an alternative.

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 one-parameter search tool with annotations and full schema coverage, the description provides the essential selection guidance. The only missing piece is a brief note on how matches are ranked or limited, which is minor in this 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 coverage is 100%, so the single query parameter is fully documented with examples. The description confirms that the query is a free-text name or partial term, but adds no syntax or matching details beyond what the schema already 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 states a specific verb (search) and resource scope (airlines and flights) and explicitly labels it as free-text search for names or partial terms. An agent can tell it apart from get_flight_wifi, get_airline_wifi, and get_tail_info without opening their 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 clearly states when to use this tool (only a name or partial term) and when not to use it (when you already have a flight number, airline code, or tail number). It says to use 'a specific tool' instead without naming the specific siblings, which leaves a small inference step.

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