United Starlink Tracker

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, open-world), and the description adds genuinely new behavior: the meaning of each return value, that assignments publish ~2 days out, that assignments can change via aircraft swaps, and the latency tradeoff versus predict_flight_starlink. This is exactly the context annotations cannot express.

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 trigger condition is front-loaded in the first sentence, followed by return-value semantics and then the routing note. Every sentence carries information the agent needs; nothing is redundant padding.

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?

There is no output schema, so the description must explain returns — and it does, enumerating all four outcome states. Combined with the timing caveat (~2 days out) and the sibling routing note, nothing material 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 description coverage is 100%, so origin, destination, date, and flight_number formats are already fully documented in the schema (including the multi-leg scoping behavior of origin/destination). The description adds no parameter-level detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource ('check' a 'flight' for Starlink) and immediately defines the answer space (YES / LIKELY YES / NO / probability estimate). It clearly distinguishes itself from predict_flight_starlink, which it explicitly names.

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 ('when the user asks "does my flight have Starlink/WiFi?" with a specific flight number and date') and names the alternative for out-of-range dates ('call predict_flight_starlink directly'). It also explains that check_flight falls through to the same estimate with extra latency, so the agent knows exactly when this tool is the right call.

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?

Annotations already declare readOnly/idempotent/non-destructive, yet the description adds substantial context beyond them: the ranking metric (coverage ratio with a concrete 92% example), that direct flights are always shown first, and critically that results are probability-ranked routings, NOT bookable itineraries because connection timing isn't validated. That last caveat is exactly the kind of expectation-setting an agent needs.

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 usage trigger, then mechanism, then the return-value caveat — a sensible priority order. It is dense but every clause (ranking metric, stop limits, non-bookable warning) earns its place; only the doubled emphasis on stops (in both prose and schema) is mildly redundant.

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

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

With no output schema, the description compensates by describing the return shape (probability-ranked routings, not bookable) and the ranking basis. Combined with the safety annotations and full schema coverage, an agent has everything needed to call and interpret this tool.

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

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

Schema description coverage is 100%, including the date-window semantics and max_stops/default limits, so the schema carries the parameter burden. The description restates the stop defaults but adds no syntax or format detail beyond the schema, matching the baseline-3 expectation when coverage is high.

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 (plan) and resource (Starlink itinerary) and self-declares as the PRIMARY travel-planning tool with multi-stop search ranked by coverage ratio. An agent can distinguish it from the narrower predict_route_starlink and search_starlink_flights siblings without opening any 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?

Opens with an explicit trigger ("Use when the user asks 'what's the best way to fly X to Y with Starlink?' or wants ranked alternatives"), which gives clear context. It does not, however, explicitly name when to prefer siblings like predict_route_starlink or predict_flight over this one, so routing among alternatives is left partly 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?

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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds substantial context beyond them: results are limited to ~2 days out, reflect a published aircraft assignment rather than a prediction, and can still change due to an aircraft swap. That caveat is exactly the kind of reliability nuance an agent needs and annotations cannot express.

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 tightly packed sentences with the use case front-loaded and the routing advice last. Every sentence carries information, though the parenthetical about origin/destination and the assignment caveat make it denser than strictly necessary for a 3-parameter lookup.

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?

There is no output schema, yet the description explains what the results represent (near-term flights with Starlink-assigned aircraft) and their reliability, plus the time horizon and the fallback tools. An agent has everything needed to call and interpret this correctly.

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

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

Schema coverage is 100%, so the three parameters are already documented and the baseline would be 3. The description adds genuinely new semantics: the schema marks zero required parameters, yet the description tells the agent that at least one of origin/destination must be supplied and that supplying both narrows to a single route.

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 (search scheduled Starlink flights) and immediately bounds the scope: near-term departures within ~2 days where the assigned aircraft is Starlink-equipped. It explicitly names the sibling tools to use for other cases, so an agent can separate it from predict_route_starlink and plan_starlink_itinerary without inspecting schemas.

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

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

It gives a concrete trigger phrase ('what Starlink flights leave from X tomorrow?'), states the input constraint (at least one of origin or destination), and gives explicit when-not guidance with named alternatives for later dates. Nothing about tool 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.