Airline Starlink Tracker

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

Annotations already cover the safety profile (readOnly, idempotent, openWorld, non-destructive), and the description adds genuinely non-structured behavior: assignment publishing horizon (~2 days out), the fact that assignments can change via aircraft swap, and the extra latency incurred versus calling the predictor directly. That is real operational context beyond the annotations.

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

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

The trigger is front-loaded and each sentence carries distinct information (trigger, return semantics, swap caveat, alternative routing). It is dense and slightly long for a four-field lookup, 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 carries the burden of explaining return values and does so exhaustively, including the no-assignment-yet probability case. Combined with the swap caveat and the sibling routing, an agent has everything needed to call and interpret it.

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

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

Schema description coverage is 100%, so the schema already documents date format, origin/destination leg-scoping, and flight-number forms. The description adds only the framing that the flight number should be a 'tracked-airline' and marketing number, which is largely reinforced by the schema examples, so 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?

States a specific verb and resource and goes further by enumerating the exact return vocabulary (YES, LIKELY YES, NO, probability estimate). It distinguishes itself from the sibling predict_flight_starlink by declaring the fall-through relationship, so an agent can tell them apart without opening either 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 ('Use when the user asks "does my flight have Starlink/WiFi?" with a specific tracked-airline flight number and date') and names the alternative (predict_flight_starlink) with the selecting condition (dates further out, where check_flight only adds latency). When-to-use, when-not, and the alternative are all 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=true, destructiveHint=false, and idempotentHint=true, covering the safety profile. The description adds the nature of the returned data (counts, percentages, per-aircraft-type breakdown), which is useful context beyond the annotations. No contradictions found.

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

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

The description is two sentences with no filler. The usage trigger is front-loaded, followed by a compact summary of the output and a clear redirection to an alternative. 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 stats tool with no parameters and no output schema, the description fully covers when to use it and what it returns. The annotations handle safety, and the description handles selection criteria. Nothing an agent needs to decide 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 tool has zero parameters, so the schema provides complete coverage. Per the rubric, a baseline of 4 is appropriate since there is no ambiguity to resolve and the description doesn't need to add parameter-level details.

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

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

The description uses the specific verb 'returns' and clearly identifies the resource as 'Starlink installation counts and percentages' across fleets. It distinguishes this tool from check_flight explicitly by stating 'Not for per-flight checks', making the purpose unambiguous.

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

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

It gives an explicit trigger ('when the user asks...') and an explicit exclusion ('Not for per-flight checks — use check_flight for that'), naming the alternative. This provides clear guidance on when to select this tool over siblings.

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 idempotentHint, so the bar is lower. The description adds useful behavioral detail: returns the 50 most recent by default, allows a limit up to 500, and specifies the exact fields returned (tail numbers, aircraft types, operators, install dates). This goes beyond the annotations without contradicting them.

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

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

Two sentences with zero filler. The use-case is front-loaded, the exclusion is explicit, and the return details are compact. Every sentence earns its place.

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

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

Given the tool's simplicity, the rich annotations, and the absence of an output schema, the description covers everything needed to call it correctly: what it returns, the default/max limit, and the clear alternative for flight queries. Nothing essential is missing.

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

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

Schema description coverage is 100%, so both parameters are fully documented in the schema. The description only reiterates the default and max limit, adding no new semantic nuance beyond the schema. 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 (list) and resource (aircraft with Starlink), and explicitly differentiates itself from search_starlink_flights. It gives concrete example user queries and lists the returned fields, making the tool's purpose unambiguous.

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

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

It clearly states when to use the tool ('when the user asks about the planes themselves') and provides an explicit exclusion and alternative ('Not for finding flights — use search_starlink_flights for that'). This leaves no ambiguity about routing.

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

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

Annotations already declare this is a safe, idempotent, closed-world read, so the safety burden is lifted. The description adds genuine behavioral scope: it only compares nonstop, per-carrier odds and explicitly redirects multi-stop UA routings elsewhere, which prevents misuse. The accuracy-window detail is already carried by the schema, so it earns no extra credit.

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 user-facing trigger, then scope, then the redirect. No filler and nothing repeated from structured fields unnecessarily.

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 tool with no output schema and fully documented parameters, the description covers purpose, trigger, scope limitation, and an alternative route for the uncovered case. It could note the shape of the comparison result (ranked itineraries vs odds), but nothing required to call it 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?

Schema description coverage is 100% — origin, destination, date window behavior, max_stops, and max_results are all fully documented in the schema. The description adds no parameter-level meaning beyond that, so the baseline of 3 applies.

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

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

States a specific verb+resource (plan a Starlink itinerary by comparing Starlink odds across every tracked airline, nonstop, per-carrier), which is concrete enough to separate it from prediction siblings. However, it never names the nearest siblings (predict_route_starlink, search_starlink_flights), so an agent must infer the boundary from scope wording alone.

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 ('Use when the user asks "what's the best way to fly X to Y with Starlink?"') and a routing condition for multi-stop UA itineraries to a different endpoint. It stops short of stating when to prefer sibling tools like predict_route_starlink or search_starlink_flights instead.

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 this as read-only, idempotent, and non-destructive, and the description is consistent with those. It adds valuable behavioral detail beyond annotations: reliability tiers by observation count, coverage differences between flight-number ranges, and the low-result branch where the date triggers a route lookup and returns a ready-made plan_starlink_itinerary call.

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

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

The description is dense but every sentence earns its place: trigger condition, output definition, reliability caveat, fleet-coverage nuance, and schema-relevant guidance. Key decision-relevant content is front-loaded in the first sentence, and the rest directly improves correct invocation.

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

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

For a two-parameter, read-only prediction tool with no output schema, this is complete. The agent knows what triggers the call, what the result means, which confidence tiers matter, how fleet split should be sourced, and what happens downstream on low-probability results. Nothing essential 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 input schema already documents both parameters with 100% coverage, so the baseline is 3. The description meaningfully adds semantics, especially for date: it must be passed when known, affects behavior on low-confidence results, and enables a pre-filled downstream call. It also clarifies flight_number formats and marketing-number preference.

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 trigger ('will my flight have Starlink?'), a temporal condition (too far out or no date), and a concrete output (probability from historical observations). It also implies differentiation from route-level prediction by focusing on flight number and mentions a sibling (get_fleet_stats) without confusion.

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 says when to use the tool: when the user asks about Starlink on a flight with a date too far out or no date. It also gives an explicit alternative call for fleet coverage data (get_fleet_stats). However, it does not explicitly say when not to use it relative to siblings like check_flight or predict_route_starlink, leaving some routing implicit.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is handled. The description adds useful behavioral detail: ranked results, no connection logic, and the empty-result semantics. It does not contradict the annotations, though it does not discuss anything like pagination or limits beyond the schema.

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

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

The description is compact and front-loaded: use cases first, then mechanics, then the alternative tool. It loses full marks because the 'both origin and destination are required' statement sits uneasily against the 'touching an airport' behavior and the origin-only example, slightly muddying an otherwise efficient structure.

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 still explains what is returned (flight numbers ranked by probability) and what an empty result means. The main gap is the unresolved destination-optionality question around 'touching an airport' and 'what Starlink flights serve airport X?', which an agent would need clarified to use the tool reliably in all described cases.

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

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

Schema coverage is 100%, so the baseline is 3; the description adds the important context that origin and destination are both required for route comparison. However, this conflicts with the schema's required-parameter count of 0 and the origin-only example, which creates genuine ambiguity for an agent deciding what to pass.

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?

Clearly identifies the resource and behavior: a single-route lookup returning tracked airlines' flight numbers ranked by Starlink probability. It also explicitly names the key sibling alternative, plan_starlink_itinerary, while the route-vs-itinerary distinction is concrete enough to prevent confusion.

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 trigger examples ('which flights between X and Y have Starlink?'), an explicit exclusion ('no connection logic or coverage-ratio ranking'), and an explicit alternative tool recommendation for connection planning. It also tells the agent what an empty result means, which is practical guidance for interpreting the response.

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.