United Starlink Tracker

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

The description discloses the three possible return outcomes (FIRM YES, FIRM NO, probability estimate) and explains the temporal context of assignment publication. It also reveals the fall-through latency behavior, adding meaningful detail beyond the readOnly and idempotent 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 with no filler. The intended use case is front-loaded, return behavior is summarized compactly, and the sibling-tool routing is stated in the final sentence. 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 read-only lookup tool, the description covers the trigger, the response semantics, the relevant time horizon, and the alternative tool when appropriate. Since annotations and the fully described schema handle safety and parameter details, nothing essential is missing 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 coverage is 100%, and the input schema already provides rich descriptions for date, flight_number, origin, and destination. The description adds some temporal meaning via 'assignments publish ~2 days out,' but the schema carries the primary parameter documentation burden, 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?

The description states a specific verb and resource: answering whether a specific United Airlines flight has Starlink/WiFi. It also distinguishes itself from predict_flight_starlink by defining the exact fallback behavior, making the tool's role 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?

It explicitly says 'Use when the user asks...' and gives a clear directive to call predict_flight_starlink directly for dates further out. This provides both a concrete trigger condition and an explicit alternative, which is exactly what an agent needs for selection.

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, so the safety profile is covered. The description goes beyond annotations by specifying the data scope and return granularity (mainline/express, per-family installed/total), which is useful behavioral context.

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, no filler. Trigger and scope come first, exclusion and alternative last. 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?

With no parameters and rich annotations, the description fully covers behavior, return values, and routing. The absence of an output schema is mitigated by the explicit description of the counts, percentages, and per-type breakdown.

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, so the schema summarizes everything. The description correctly omits parameter details; baseline 4 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 trigger query and explicit return content: installation counts and percentages across mainline and express fleets, plus per-aircraft-type breakdown. Distinguishes itself from check_flight, making its scope unmistakable.

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

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

Explicitly says when to use it ('how far along is the Starlink rollout?'), what it covers, and gives a clear exclusion: 'Not for per-flight checks — use check_flight for that.' An agent needs no inference to route 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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds concrete behavioral details: the exact fields returned (tail numbers, aircraft types, operators, install dates) and the default/max limit, as well as ordering (most recent). No contradictions 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, zero fluff. The first sentence immediately states purpose and gives example queries; the second covers return fields, defaults, limits, and the exclusion. Everything 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 only two optional parameters and no output schema, the description covers all essential information: what it returns, default behavior, maximum limit, and when to choose an alternative. No gaps remain 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 description coverage is 100% with clear descriptions for both fleet ('Filter to only express (regional) or mainline aircraft') and limit ('Maximum number of aircraft to return (default 50)'). The description only reiterates the limit (up to 500) without adding new semantics, so per the baseline rule for high coverage, a 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 opens with a precise use case ('when the user asks about the planes themselves') and gives concrete example queries ('which tail numbers have Starlink?'). It clearly names the resource (United Airlines aircraft) and the action (list with details), and explicitly differentiates from the sibling search_starlink_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?

It explicitly states when to use the tool and when not to, pointing to the exact alternative ('Not for finding flights — use search_starlink_flights for that'). It also explains the default behavior (50 most recent) and the upper limit (500), leaving no ambiguity about invocation 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?

Beyond the annotations (readOnlyHint, idempotentHint, destructiveHint), the description discloses critical behavioral details: results are probability-ranked, not bookable, connection timing is not validated, and verification on the airline's site is required. It also explains the coverage-ratio algorithm and the direct-flights-first rule, which helps the agent set correct expectations.

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 compact sentences with high information density. The first sentence front-loads the usage trigger and primary status; the second packs the algorithm, ranking criteria, and output caveats. 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 tool with 5 parameters and no output schema, the description covers the essential behavior, ranking logic, and limitations. It leaves out the exact result structure and how max_results interacts with appended baselines, but the schema handles parameters and the core planning behavior 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?

Schema description coverage is 100%, so the baseline is 3. The description repeats max_stops defaults but does not add deeper meaning beyond the schema for parameters like date or max_results. It does not need to compensate because the schema already fully documents each 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?

The description states a specific verb ('plan') and resource ('itinerary'), defines the tool as the 'PRIMARY TRAVEL-PLANNING TOOL', and explains its ranking by coverage ratio. It clearly differentiates from sibling tools by focusing on multi-stop itinerary planning and explicitly saying it returns routings, not bookable itineraries.

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 ('Use when the user asks ...') and positions itself as the primary planning tool, which provides clear context for when to use it. However, it does not name sibling alternatives or state when not to use it, so it stops short of full when/when-not 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 readOnly/openWorld/idempotent annotations, the description discloses non-obvious behavior: results are derived from historical observations, reliability is tiered (5+ obs is high-confidence but not a guarantee, 0-1 obs is just the fleet prior), and coverage varies materially by flight-number range. This gives the agent the right expectations and cautions, and it does not contradict 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?

Four sentences, each carrying distinct information: use condition, result definition, reliability caveat, and fleet-split alternative. It is front-loaded and free of 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?

The tool is simple (2 params, 1 required), annotations already cover the safety profile, and the schema documents the optional date side effect. The description contributes reliability and coverage context, so an agent has enough to select and invoke the tool correctly despite lacking an output 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 100%, so the baseline is 3; the description adds interpretation value by explaining coverage differences across flight-number ranges and directing the agent to get_fleet_stats for the current split. Parameter syntax and date behavior are already thoroughly handled in the schema, so no higher score is warranted.

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 concrete trigger ('will my flight have Starlink?') and defines the operation as returning a probability that a United flight number gets a Starlink plane from historical observations. It also scopes use to future/no-date cases, which distinguishes it from confirmed-assignment lookups and from fleet-level 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 explicitly says when to use the tool (date too far out for a confirmed assignment, or no date) and provides a when-not/alternative by telling the agent to call get_fleet_stats for the current UA1-2999 vs UA3000-6999 split rather than assuming a rate. This is concrete routing guidance with a named sibling.

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 read-only, idempotent, and non-destructive. The description adds meaningful runtime behavior: results are ranked by Starlink probability, an empty result means the route is not served by Starlink planes, and there is no connection logic or coverage-ratio ranking. There is no contradiction 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?

Three sentences pack the trigger, behavior, parameter pattern, alternative, and empty-result semantics with no filler. The most important usage information is front-loaded.

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 three-parameter lookup with no output schema, the description covers when to use it, how to combine parameters, what results contain, what an empty result means, and when to choose an alternative. The schema handles the default limit, so nothing needed to call the tool correctly 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?

The schema fully documents all three parameters with types, examples, and a default for limit. The description adds the key combination rule—pass both origin and destination for a route, or one for an airport list—which is not evident from the schema alone.

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 explicit user-query triggers and a precise statement of behavior: returns United Airlines flight numbers on a route or touching an airport, ranked by Starlink probability. It names the closest sibling (plan_starlink_itinerary) and contrasts this tool's single-route scope, so the agent can distinguish it from the itinerary planner.

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 concrete when-to-use examples ('Use when the user asks...'), specifies the two valid calling patterns (both origin+destination or just one), and explicitly routes connection-based trip planning to plan_starlink_itinerary, stating 'this tool has no connection logic or coverage-ratio ranking.'

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, so the safety profile is covered. The description adds valuable context beyond annotations: the 'confirmed vs predicted' data distinction, the ~2-day window, and the limitation that 'aircraft assignments aren't published further out'. 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, each earning its place: the usage trigger, the core function and data nature, and the parameter constraint plus alternative routing. The most decision-relevant information is front-loaded.

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 search with 0 required params and no output schema, the description covers when to use, what it returns, the time window, and param requirements. It doesn't describe the return format, but for a flight-list search this is a minor gap given the clarity of the rest.

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 the relational constraint 'Pass at least one of origin or destination (both narrows to a single route)', which is not present in the individual parameter descriptions. This meaningful cross-parameter guidance justifies a 4.

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: 'Returns CONFIRMED Starlink flights in the next ~2 days'. The 'firm schedule, not prediction' phrase distinguishes it from prediction siblings, and the description names predict_route_starlink/plan_starlink_itinerary as alternatives. An agent can immediately tell this apart from the other 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?

Gives an explicit trigger condition ('Use when the user asks "what Starlink flights leave from X tomorrow?"') and explicit exclusions with named alternatives ('for later dates use predict_route_starlink or plan_starlink_itinerary instead'). 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.