SkyGlance

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

With no annotations provided, the description carries the behavioral transparency burden. It discloses the read-only lookup nature, the input format, and the exact output fields. It does not discuss error handling for invalid codes, but for a simple lookup tool this is 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?

The description is concise, front-loads the primary lookup action, and uses examples economically. Every sentence adds value, and the line breaks make it scannable.

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 lookup tool with no output schema, the description is complete: it explains the input, the expected output fields, and gives concrete examples. Nothing essential is missing for an agent to call the tool 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?

The input schema merely says 'Code' with no description, so parameter semantics rely entirely on the tool description. The description clearly defines code as an ICAO code, explains it is the callsign prefix, and provides real-world examples. This fully compensates for the 0% schema description 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 uses a specific verb and resource: 'Look up an airline by its ICAO code' and clearly states what will be returned (name, IATA code, country, callsign). The examples (JBU, BAW, UAE) make the tool's purpose unambiguous and distinguish it from aircraft-centric siblings like identify_aircraft or search_aircraft.

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 clearly implies when to use the tool: when you have an ICAO airline code and need airline metadata. It does not explicitly name alternative tools or state when not to use it, but the examples and the focus on airline codes give sufficient operational 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?

With no annotations present, the description carries the full burden of disclosing behavior. It explains that buckets are inferred from position and climb/descent rate, that no schedule/gate/destination knowledge exists, and that nearby-airport misattribution is possible. This is substantial behavioral transparency, though it does not mention output format, freshness, or rate 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?

The description is compact, front-loaded with the core concept, and every sentence adds useful context. The structure flows naturally from definition to inference behavior to caveats, with no wasted words.

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 description does a good job of explaining the tool's behavioral model and limitations, which matters because there is no output schema and no annotations. However, it omits explicit parameter semantics and does not clearly state when to choose this over sibling tools, leaving an agent with some ambiguity in real selection scenarios.

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

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

Schema description coverage is 0%, so the description must explain the parameters, but it only implies 'nearby' and 'airport' without defining `icao` or `radius_nm`, including units, defaults, or behavior. The agent is left to infer that `icao` identifies the airport and `radius_nm` controls the search area, which is a significant gap at this coverage level.

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

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

The description clearly states what the tool does: it reports what is moving around an airport right now, observed rather than scheduled, and groups aircraft into departing, arriving, on the ground, and overflying. It also explicitly differentiates itself from a departure board, making its purpose and scope immediately clear.

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 practical usage context by emphasizing that this is observed activity, not scheduled information, and warns about misattribution near multiple airports. It does not explicitly name alternative tools or give a direct when-to-use sentence, but the limitations and exclusions effectively guide the agent's choice.

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?

With no annotations, the description carries the behavioral disclosure burden, and it does this well: it states that the measurement is observed activity rather than scheduled movements, and it openly warns that airports in poorly covered regions may look quiet. This is genuinely useful caveat information. It does not mention output ordering or pagination, but those are less critical for a ranking query.

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 four concise sentences, each earning its place: the core question, the counting method, the optional filter, and an important data caveat. The most important information is front-loaded and there is no 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 read-only ranking tool with two optional parameters and no output schema, the description gives enough behavioral context to call it correctly and interpret the result: global major airports, an optional country filter, and a coverage caveat. It could be more complete by mentioning how the returned list is ordered or how limit affects the response, but it is not a significant gap.

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 description explains the country parameter well with concrete examples like US, GB or IN, which adds value beyond the raw schema. However, it does not explain what limit controls beyond what the name and default value imply, and schema description coverage is 0%, so the description had to compensate more fully than it did.

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

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

The description clearly identifies the resource (major airports) and the exact measurement (counts of aircraft on the ground or manoeuvring nearby), so an agent knows what the tool computes. It also explains the optional country filter. It does not explicitly contrast with the closely related sibling airport_activity, so it stops short of perfect sibling differentiation.

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 strong context for when the tool is appropriate: asking which major airports currently have the most observed aircraft traffic, optionally within one country. However, it never tells the agent when to prefer this over airport_activity or the other sibling tools, so routing decisions are 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?

With no annotations, the description fully carries the transparency burden and does so admirably. It discloses the refusal to predict beyond 90 seconds, the accuracy degradation over time, and the fallback behavior of reporting distant objects as 'inbound' with no countdown.

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 front-loaded with the core purpose, then provides a concise and well-organized rationale for the tool's limitation. Every sentence contributes meaningful context without 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?

The behavioral context is rich and the tool is simple, but the lack of any parameter explanation and the absence of an output schema leave gaps. An agent can infer the main use case, but not the exact role of lat/lon or the expected response shape.

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 has 0% description coverage and the description adds nothing about the lat/lon parameters. It never explains that these are the observer's coordinates, what units to use, whether they are mandatory, or what happens if they are omitted. The bare property names provide minimal signal, but the description fails to compensate.

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

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

The description clearly identifies the tool's function: reporting what will pass overhead within the next 90 seconds. The precise time window and the explicit refusal to predict further out distinguish it from related sibling tools like whats_overhead.

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 clear when-not-to-use guidance: it deliberately stops at 90 seconds and explains why longer predictions would be unreliable. It does not name specific alternative tools, but the behavioral constraints effectively tell an agent not to use this tool for longer-horizon questions.

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?

With no annotations, the description carries the behavioral disclosure burden. It explains the three emergency squawk codes and, importantly, states that a zero result is normal and desirable rather than a failure. This prevents misinterpretation of an empty response, though it does not discuss data freshness or response format.

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: subject and scope first, then code meanings, then a behavioral caveat. Every sentence adds useful information with no filler.

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

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

For a zero-parameter worldwide status tool, the description is largely complete: it names the data set, the relevant codes, and the expected normal state. A minor gap is that it never explicitly says the tool returns a list of aircraft, though the noun-phrase opening implies 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?

The tool has zero parameters, so the baseline is 4 and there is nothing to document. The description appropriately focuses on output semantics instead of inputs.

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 identifies a specific resource—aircraft squawking emergency codes—and a worldwide scope, which distinguishes it from sibling tools like military_aircraft or interesting_nearby. It lacks an explicit verb such as 'lists' or 'shows', but the intent is clear enough.

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

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

Usage is implied: use this tool to see aircraft currently squawking emergency codes worldwide. No explicit alternatives or when-not-to-use guidance is given, but the code breakdown and normal-zero caveat give some contextual framing.

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?

With no annotations, the description carries the behavioral burden, and it adds valuable context: these are 'volunteer-run services with no SLA,' and 'three are queried rather than one' to compensate for outages. This explains why latency or failures may be present and why redundant queries happen. It does not explicitly state read-only behavior, but that is strongly implied by a health-check tool.

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 first sentence states the core result, and the second provides architectural context that explains the tool's behavior. 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 zero-parameter health-check tool with no output schema, the description sufficiently explains what the tool reports and why the data looks the way it does. It could have mentioned the exact return format or source names, but that is not necessary for an agent to select or invoke the tool 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?

The tool has zero parameters and 100% schema coverage, so the description is not required to explain inputs. The description instead focuses on what the tool measures, which is the only parameter-relevant information needed here.

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

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

The description clearly identifies the tool's focus: 'Per-source health: latency, failures, and whether a circuit breaker is open.' This goes beyond a tautology and names specific metrics. It doesn't use an explicit verb like 'get' or 'report,' but the meaning is unambiguous and distinct from the aircraft-focused sibling 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?

The description implies this is used for checking feed health and explains the redundancy of querying three services, but it does not explicitly state when to choose this tool over alternatives or when not to use it. Sibling names like poller_status might overlap in intent, so an explicit usage boundary would have been stronger.

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?

With no annotations, the description must carry the behavioral disclosure burden. It does communicate the main behavior: the result set is every airborne aircraft of the given type, worldwide by default and optionally nearby. It does not explain how near_me interacts with lat, lon, and within_km, nor does it mention data freshness or response characteristics, but for a read-only lookup the essential behavior is present.

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: the core behavior appears in the first line, followed by useful examples and a brief filter instruction. Every sentence earns its place; there is no filler or redundant restatement of the tool name.

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

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

For a tool with no annotations, no output schema, and five parameters, this description is too sparse. It does not clarify the relationship between near_me, lat, lon, and within_km, nor does it explain the default worldwide behavior well enough to prevent incorrect assumptions. It also does not distinguish itself from nearby sibling tools such as search_aircraft or fleet_view.

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

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

Schema description coverage is 0%, so the description must compensate. It adds real value for type_code with concrete ICAO examples and gives a brief hint that near_me toggles filtering. However, lat, lon, and within_km are left entirely to inference, even though their interaction with near_me is important for correct invocation.

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 the core purpose clearly: list every airborne aircraft matching one ICAO type code, either worldwide or nearby. The example codes make the type_code parameter concrete and help disambiguate it from aircraft-by-registration or aircraft-by-route tools. It does not explicitly name a sibling alternative, but the 'one ICAO type code' scope is a strong differentiator.

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 implies when to use the tool: when you want all airborne aircraft of a specific ICAO type, globally or near the user. It also tells the agent to set near_me to filter to a local area. However, it gives no guidance on when not to use this tool or which sibling tool should be preferred for related queries, so the usage guidance is only 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?

With no annotations provided, the description carries the full burden of disclosing behavior. It clearly states that the tool 'Reads one shared global snapshot rather than querying per aircraft, so it is cheap to ask repeatedly,' and it explicitly warns about the volunteer receiver coverage limitation. This is exactly the kind of behavioral context an agent needs to interpret results correctly.

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 well-structured: it leads with the core purpose, then provides input format and alternative routing, and finally adds relevant behavioral caveats. Every sentence contributes meaningful information without redundancy or filler. The front-loading of the main purpose makes it easy for an agent to scan and understand.

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 fleet lookup tool with two parameters and no output schema, this description is nearly complete. It tells the agent what the tool returns (airborne flights), how to format the required input, when to use a sibling instead, and how to interpret incomplete data. The only minor omission is explicit limit semantics, but the parameter name and default make that low-risk.

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 description provides strong semantic guidance for the 'airline' parameter by explaining the ICAO format, examples, and the IATA alternative. However, it says nothing about the 'limit' parameter, and the schema has no description for it either. The limit parameter seems inferable from its name and default, but the description does not explicitly clarify its behavior or acceptable range.

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 statement: 'Every flight an airline currently has airborne, worldwide.' This clearly identifies the resource and scope, and the tool name fleet_view reinforces the purpose. It also distinguishes itself from related tools like track_flight and airline_info, making the intent 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?

The description gives explicit usage guidance: 'Give the ICAO airline code' and 'Use airline_info if you only have the two-letter IATA code.' It also explains the data source and coverage caveat, helping the agent decide when this tool is appropriate versus alternatives. This goes beyond generic instructions and provides concrete decision criteria.

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?

With no annotations, the description carries the behavioral disclosure burden. It discloses a key limitation: the data is always an undercount and sparse receiver coverage means oceans, Africa, and central Asia are absent. It also explains it is a single shared snapshot. It does not mention refresh cadence or output format, but the caveat is substantial and useful.

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 paragraphs with a front-loaded core question, a scope sentence, and a one-sentence caveat. Every sentence earns its place; there is no fluff or repetition.

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's mention of totals, busiest types, and airlines is important and mostly sufficient for an agent to know what to expect. It could add exact output shape or update cadence, but for a parameterless aggregate endpoint the description is adequately complete.

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 there are no parameter semantics to clarify. The baseline for a no-parameter tool is 4, and the description appropriately focuses on what the returned snapshot represents rather than inventing parameter 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?

The description states a clear purpose: showing how much is flying worldwide now, with totals, busiest types, and airlines. It is recognizable as a global aggregate view and implicitly distinguishes from sibling tools like busiest_airports or spotting_stats, though it does not explicitly contrast any sibling.

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 implies when to use this tool: when you want a worldwide current-traffic snapshot. It adds a valuable coverage caveat. However, it never explicitly says when not to use it or names alternatives such as spotting_stats, busiest_airports, or viewing_conditions.

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?

With no annotations provided, the description carries the burden of behavioral disclosure. It usefully reveals that results are cached permanently and explains the rationale, but does not mention potential side effects, permissions, rate limits, or error behavior. This is adequate but not fully transparent.

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 concise sentences, front-loaded with the purpose, followed by the input rule and caching behavior. Every sentence adds useful information with no filler.

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

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

For a low-complexity tool with no output schema and no annotations, this description covers the operation's purpose, input options, expected output fields, and caching behavior. The remaining gap is the lack of explicit 'exactly one parameter' enforcement and identifier formats, but the description is otherwise sufficient for a confident call.

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

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

The schema has 0% description coverage, but the description adds the essential real-world meaning for all three parameters by mapping them to ICAO hex, registration, and callsign, and states that any one is sufficient. It could improve by specifying format examples or how multiple supplied params are handled.

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 deliverable: 'Full identity for one aircraft: type, operator, route, and a photograph.' This clearly distinguishes individual identity lookup from sibling tools like find_by_type or search_aircraft, which cover broader queries.

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 tells the agent how to invoke the tool: 'Give any one of an ICAO hex, a registration, or a callsign.' However, it does not state when not to use this tool or name alternatives, so it stops short of a full when/when-not guide.

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?

With no annotations provided, the description carries the full burden of explaining behavior. It does so reasonably by describing scoring categories, threshold-based filtering, and the deliberately harsh threshold tuning with an approach-path example. Missing details include whether the tool mutates anything, how location defaults are handled, and what the returned aircraft data looks like.

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. The first sentence immediately communicates the tool's value, the second explains the scoring mechanism, and the third provides useful calibration context. Every sentence earns its place without redundancy or fluff.

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 description captures the core selection logic and is viable for a straightforward call with explicit lat/lon/radius/minimum_score. However, it does not explain what happens when lat and lon are null, how radius_nm and minimum_score interact, or what the returned aircraft objects contain. Since there is no output schema, more operational detail would be needed for full completeness.

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

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

Schema description coverage is 0%, so the description needs to compensate, but it never mentions lat, lon, radius_nm, or minimum_score. An agent must infer that 'nearby' maps to lat/lon/radius and 'threshold' maps to minimum_score. The parameter names and defaults are somewhat self-explanatory, but the description adds no direct parameter-level meaning.

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

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

The description clearly identifies a filter-and-score tool for nearby aircraft, listing specific categories that make an aircraft interesting (emergency, rare type, military, large-and-low, close low helicopter) and stating that only those above threshold are returned. It is specific about the resource and action, though it does not explicitly contrast itself with sibling 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?

Use is implied: this is for when the user wants only notable aircraft rather than all traffic. The opening phrase and threshold discussion convey the intended context, but there is no explicit when-to-use/when-not-to-use guidance and no mention of alternatives like emergencies, military_aircraft, or whats_overhead.

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?

No annotations are provided, so the description carries the full burden of explaining behavior. It states the query concept but does not disclose what 'seen before' means, how location is determined, whether the operation records anything, or what the response indicates.

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

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

One short sentence with no filler; the core idea is front-loaded. It is appropriately concise, though the brevity comes at the cost of operational detail.

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 three optional parameters, no output schema, and no annotations, an agent has little information about what the tool returns or how the three identifiers interact. The description is too minimal to be fully actionable in a multi-tool 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 description coverage is 0%, so the description must compensate, but it only loosely maps 'airframe' to hex_id/registration and 'type' to type_code. It does not explain each parameter's role, required combinations, or how registration relates to the other identifiers.

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

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

The description clearly frames the tool as a check for whether a specific airframe or type has been seen over the user's location before, which is a distinguishable purpose. It lacks an explicit imperative verb like 'determine' or 'check', and doesn't name sibling distinctions, but the intent is not vague.

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

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

There is no guidance on when to use this tool versus alternatives such as sighting_history or whats_overhead. The only implied context is a novelty question, but no explicit exclusions or alternative conditions are provided.

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?

With no annotations provided, the description carries the full burden. It states the real-time aspect ('currently airborne') and the filtering behavior, which gives basic transparency. However, it does not disclose response format, pagination, data limitations, or whether this is a read-only operation beyond what is implicitly obvious.

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 short sentences with no filler. It front-loads the core purpose and then gives the key usage instruction for the main filter, making it easy for an agent to parse.

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 no annotations, no output schema, and no parameter descriptions in the schema, the description leaves important gaps. It does not explain lat/lon semantics, the default worldwide behavior, what the response will contain, or any limitations. The core idea is present, but an agent may not know how to correctly construct location-based requests or interpret results.

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

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

Schema description coverage is 0%, so the description must compensate for all four parameters. It explains near_me and within_km indirectly, but lat and lon are not described at all, leaving their role ambiguous. The phrase 'near a location' hints at coordinates but does not clarify how lat/lon are used or whether they are required together.

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

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

The description clearly states the tool returns 'Military aircraft currently airborne' and defines the geographic scope as 'worldwide or near a location.' It identifies a specific resource and behavior, distinguishing it from generic aircraft tools, though it does not explicitly differentiate it from sibling tools by name.

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 clear operational context: use this to find military aircraft currently airborne, with an optional location filter. It explicitly explains when to set near_me to true, but it does not provide exclusions or mention alternative sibling tools for comparison.

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?

No annotations are present, so the description carries the full burden of behavioral disclosure. It states only that the tool provides personal extremes, but it does not explicitly say the operation is read-only, what data source it uses, whether values are all-time or time-bounded, or what the output shape is.

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 extremely short and front-loaded, opening with 'Your personal extremes' before listing categories. Every word contributes, though the fragmentary phrasing prevents a perfect 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 tool with no parameters and no output schema, the list of extremes provides a minimal viable sense of what is returned. However, it leaves ambiguities such as 'closest' and 'lowest' of what, whether these are all-time or recent, and the exact output format, so an agent may need to discover these details from results.

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 has zero parameters, so there are no parameter semantics to document; the 0-parameter baseline of 4 applies. The description does not add parameter-level detail because none is needed.

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?

Identifies the resource as the user's personal records and lists specific extremes (closest, lowest, most directly overhead, busiest day), which distinguishes it from global/current-view siblings. However, it lacks an explicit verb such as 'returns' or 'shows', so it stops short of a full 5.

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

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

No guidance is given about when to use this tool versus siblings like sighting_history, spotting_stats, or global_stats. The word 'personal' implies a distinction, but there is no explicit when-to-use/when-not-to-use or alternative comparison.

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 description adds useful behavioral context beyond a bare label: it specifies the ordering metric (slant range), the temporal scope (right now), and the visibility inclusion. However, with no annotations provided, the description carries the full burden and does not disclose what happens when lat/lon are null, what the return structure looks like, or any rate/feed behavior.

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 a single concise sentence that front-loads the core behavior and includes a meaningful differentiator at the end. There is no repetition, filler, or schema information duplication.

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 no annotations and no output schema, the description is too thin: it leaves coordinate default behavior, count semantics, and response format unstated. A minimal viable description for this spatial query tool would need at least one sentence explaining how the optional lat/lon values are used and what the returned list contains.

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

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

Schema description coverage is 0%, so the description must compensate for parameter meaning. It implicitly ties lat/lon to the reference location for 'closest' and slant range, but it does not explain the null defaults, how count behaves, or how many results are returned. The property names are self-evident, but important semantics like fallback location are 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?

The description clearly identifies what the tool returns: the closest aircraft by slant range, right now, with no visibility filter. It distinguishes itself from visible-only sibling tools like coming_overhead or whats_overhead by explicitly including non-visible aircraft. It lacks an explicit verb like 'find' or 'list', but the intent is 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?

There is no guidance about when to choose this tool over the many sibling tools, nor any mention of alternatives. The description implies a real-time proximity query, but it does not state prerequisites, coordinate fallback behavior, or how it differs from tools like coming_overhead or interesting_nearby.

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?

No annotations are provided, so the description carries full behavioral burden. It does convey that the tool is a read-only status check with no side effects implied, and it indicates the output will describe running state plus captured data. However, it doesn't disclose detail like what 'captured' means, whether data can be empty, or whether any background process state is affected by calling this tool.

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 a single clear sentence that front-loads the core purpose and the type of information returned. There is no filler or redundant wording, and the length is appropriate for a zero-parameter status tool.

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 zero-parameter status tool, the description gives enough context to understand the purpose and general output. Since there is no output schema, a bit more detail about the exact shape or examples of return values would strengthen it, but the description is largely sufficient for an agent to decide to invoke 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?

There are zero parameters and the schema describes the empty object completely, so no parameter explanation is needed. The description adds no parameter information, which is appropriate because there are none to document.

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

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

The description clearly identifies a specific status resource: whether background history recording is running and what it has captured. It doesn't explicitly differentiate from siblings like track_history or feed_health, but the phrasing is specific enough that an agent can tell it is a status/query tool rather than a recording or retrieval tool.

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

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

No guidance is given about when to call this tool versus alternatives such as track_history or sighting_history. There are no stated preconditions, exclusions, or scenarios where this tool should be preferred, so the agent must infer usage from the name and vague description.

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?

With no annotations provided, the description carries the behavioral disclosure burden and does it well for data expectations: it warns that positions are real, the identity is obscured by design, and users should not expect a registration or owner. It also supplies useful LADD/PIA context, though it stops short of describing the response format or filtering behavior.

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 organized into three short paragraphs, front-loading the core subject before adding background. The LADD/PIA explanation is relevant context rather than filler, though the opening is a noun phrase rather than a crisp action-oriented statement.

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 and no annotations, so the description needed to explain what the tool returns and how the optional spatial parameters affect results; it does neither. The privacy caveat is valuable, but the description is not complete enough for an agent to know what a successful invocation will produce or how to configure the search.

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

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

Schema description coverage is 0%, and the description adds nothing about lat, lon, near_me, or within_km. The parameters are left entirely to inference, with no explanation of how location filtering works, what near_me means, or how within_km interacts with the coordinates.

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 identifies the subject clearly ('Aircraft using privacy programmes that hide their identity on most trackers') and implies the tool surfaces these aircraft, but it never states an action verb such as list, get, or retrieve. The tool name and sibling context help, but the description alone does not fully specify the operation.

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

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

There is no explicit guidance on when to use this tool versus alternatives like military_aircraft, identify_aircraft, or nearest_aircraft. The explanation about adsb.lol publishing unfiltered data hints at the tool's niche, but it does not state when this tool is preferred or when it should be avoided.

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?

No annotations are provided, so the description carries the burden. It discloses that results are airborne aircraft and that filtering is combinable and optionally location-based, which is useful. However, it does not mention default behavior such as the limit of 40, what happens when no filters are supplied (likely returns a general sample), or whether the result is sorted/ranked — leaving the agent to infer the default behavior.

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 well structured: an opening sentence states the core purpose, a second sentence summarizes filter categories and scope, and three short example queries make the intended usage concrete. Every sentence earns its place without 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 12-parameter tool with 0% schema coverage, no annotations, and no output schema, the description conveys the most important semantic pieces: filter types, combinability, geographic scoping, and real-world query patterns. It does not cover the limit default or explicitly describe the result set shape, but the examples and filter enumeration bring it to a reasonably complete level.

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

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

Schema coverage is 0%, so the description must compensate, and it does: it explains the semantic meaning of airline (ICAO code), type_code (aircraft type, with the '747' example), altitude band, speed band, military status, and the near-location/within-distance concept. However, it does not explicitly mention the limit parameter or the near_me toggle, so a couple of parameters remain unaddressed.

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 a specific verb ('Find') with a clear resource ('airborne aircraft') and explicitly states it is a general, multi-filter search. It distinguishes itself from siblings by naming what it is ('This is the general search') and providing concrete query examples covering the main filter dimensions (type, airline, altitude, speed, location).

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 strong usage context: 'any combination of filters' plus 'worldwide or within a distance of a location' and labels this as the general search. It does not explicitly name sibling alternatives or state when not to use them, so it falls short of a 5, but the examples and scope statement give an agent enough to select this tool.

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?

With no annotations, the description carries the full burden of behavioral disclosure. It does disclose a key behavioral trait: results are returned with the most recent first. However, it does not explain other behavioral aspects like how the optional filters behave, whether there is pagination beyond the limit parameter, or what happens when no aircraft identifier is 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?

The description is a single concise sentence that immediately communicates the core function and ordering. Every word adds value, and no filler or redundant phrasing is present.

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 has three optional parameters with no schema descriptions, no annotations, and no output schema, so the description must be more complete to support correct invocation. It leaves the agent uncertain about parameter semantics, return structure, and how this tool relates to the many sibling history/record tools. This is inadequate for a full understanding.

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

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

Schema description coverage is 0%, so the description must compensate for explaining limit, hex_id, and registration. It only hints that an aircraft is identified (which could map to hex_id or registration), and it gives no meaning for the limit parameter. The agent cannot infer from the description how filtering or limiting works.

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 a specific verb and resource: it returns recorded passes of an aircraft over the user's location. The ordering 'most recent first' adds further precision. This distinguishes it from sibling tools like track_history (flight path history) or my_records, because it scopes results to a single aircraft and the user's location.

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 implies the tool should be used when an agent needs historical sighting records for an aircraft, especially ordered by recency. However, it does not explicitly state when to choose this over tools such as track_history, my_records, or spotting_stats, nor does it provide exclusions or example scenarios.

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?

With no annotations provided, the description carries the burden of explaining behavior. It usefully discloses the output dimensions: totals, most common types, and busiest hours. However, it does not mention read-only status, the effect of the days parameter, or any aggregation specifics.

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 a single concise phrase with no filler, and the colon structure front-loads the purpose before listing output categories. It is efficient, though it omits parameter information that would improve completeness.

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 one optional parameter, no annotations, and no output schema, the description is incomplete. It covers what statistics are returned but fails to explain the days parameter, which is essential 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 0% and the single parameter 'days' is completely undocumented in the description. An agent cannot determine whether days is a filter, how null is handled, or what units are expected. The description offers no compensation for the schema gap.

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

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

The description 'How much you've seen: totals, most common types, busiest hours' clearly conveys that this tool reports personal spotting statistics and lists the concrete output categories. It is distinguishable from siblings like global_stats and sighting_history through the personal 'you've seen' framing, though it does not explicitly name those alternatives.

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

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

No when-to-use guidance is provided, and no alternatives or exclusions are mentioned. The description implies this is for personal summary stats but does not tell the agent how to choose it over global_stats, my_records, or sighting_history.

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?

With no annotations, the description carries the full burden and does provide a key behavioral detail: it returns nothing for two indistinguishable cases—not currently airborne or outside receiver coverage. It also discloses the global feed search behavior. This goes beyond a simple tautology and gives the agent important expectations about empty results.

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 concise sentences: the first immediately states the purpose and scope, the second adds essential behavioral and coverage context. Every word earns its place with no fluff or repetition.

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?

While the description clarifies scope and an important edge case, it does not explain what a successful result contains—there is no output schema—nor does it define parameter requirements or differentiation from siblings. For an agent to call this tool correctly, it still needs parameter and output semantics, which are 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 description coverage is 0%, and the description does not mention callsign or registration at all. There is no guidance on whether at least one is required, how they interact, or what format to use. The description fails to compensate for the bare schema, leaving the agent without necessary parameter semantics.

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-resource relationship: locating a specific flight's current position anywhere in the world. It also distinguishes itself from circle-based tools by explicitly noting 'Searches the whole feed rather than a circle,' though it does not name a sibling. This is clear and actionable.

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 implies when to use this tool—when you need a worldwide look for a specific flight rather than a local area—but it does not explicitly contrast with siblings like track_history or nearest_aircraft. No explicit 'use X instead' guidance is given.

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

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

No annotations are present, so the description carries the behavioral burden. It discloses the ~24-hour sliding window, downsampled paths, and the interpretation of long straight jumps as volunteer-coverage gaps. This is meaningful behavioral context beyond the raw schema, though it does not address auth, rate limits, or exact output formatting.

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 front-loaded with the core purpose, then gives example user questions, then closes with the essential caveats. Each sentence earns its place and nothing feels redundant or padded.

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 and no annotations, the description usefully explains return fields, leg structure, time window, and coverage gaps. However, it leaves the input-selection contract unresolved: three optional identifiers with no guidance about which to use, and it does not explicitly route the agent to a sibling when an archive is needed.

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

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

Schema description coverage is 0%, and the description does not explain how hex_id, callsign, or registration select the aircraft, whether at least one is required, or whether they can be combined. The property titles are somewhat self-explanatory, but the description adds no parameter semantics and leaves the all-optional behavior unclear.

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 says the tool 'Returns each airborne leg' with when it started and ended, distance, altitude, and a path, and explicitly frames it as answering 'where has this plane been today.' This is a specific verb plus resource and is clearly distinguishable from broader siblings like track_flight or sighting_history.

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 clear usage context: use this for a single aircraft's roughly-last-day leg history and route. It also draws an exclusion boundary by saying 'Not a flight archive' and explains that long straight jumps are receiver coverage gaps rather than real flight paths. It does not name the alternative sibling to use for archives, so it is slightly less explicit than it could be.

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?

With no annotations, the description carries the full behavioral burden, yet it is a noun-phrase tagline rather than an operational statement. It names three condition factors but does not say whether it returns current conditions, how it handles absent lat/lon values, whether it is read-only, or what the output actually looks like.

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 a single concise clause with the core content (cloud, visibility, daylight) front-loaded and the evaluative purpose after the dash. Every word contributes and there is no repetition of schema or annotation information.

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

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

For a tool with no output schema and no annotations, the definition is too thin: it omits the role of the optional coordinates, the temporal scope, and the return format. It is evocative but leaves important selection and invocation details unstated.

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

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

Schema description coverage is 0%, so the description must compensate, but it never mentions lat or lon. The parameter names are self-explanatory, yet the optional/default-null behavior and how missing coordinates are interpreted remain undocumented.

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

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

The description clearly identifies the resource (cloud, visibility, daylight) and the intended decision point via "whether it's worth looking up at all," making it distinct from the aircraft-focused sibling tools. It would reach 5 with an explicit verb like 'returns' or 'checks'.

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 phrase "whether it's worth looking up at all" implies the tool is for deciding if sky conditions are good for observation, but it gives no explicit when-to-use guidance, exclusions, or comparisons to alternatives. The agent must infer when to use it among the sibling tools.

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

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

With no annotations, the description bears full responsibility for behavioral disclosure. It reveals useful behavior: aircraft are ranked by noticeability (directly overhead first, about-to-be overhead second, then by elevation) and viewing conditions are included. However, it does not state what happens when lat/lon are null, how fresh the data is, or what the response shape looks like when no aircraft are 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 compact, front-loaded, and every sentence earns its place. It states the question, the ranking behavior, and the rationale for including viewing conditions without digresing.

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 description covers the core scenario and result ordering well, but it leaves important gaps: no parameter semantics, no explicit guidance on choosing between this and overlapping siblings like coming_overhead, and no indication of what the returned data includes beyond ordering. Given no annotations and no output schema, a more complete description would strengthen an agent's ability 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 0% and the description mostly ignores the parameters. It only implies lat/lon through 'above a location' and gives no meaning for limit or radius_nm, including units or how they affect results. The property names and defaults in the schema are not enough to compensate for this gap.

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

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

The description clearly states this tool returns aircraft currently above a location, ordered by what a person would actually notice, and includes viewing conditions. This specific purpose distinguishes it from siblings like coming_overhead and viewing_conditions by combining 'what is overhead right now' with 'where to look'.

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 establishes a clear use context: current sky visibility and 'where to look', which tells an agent this is for immediate, observation-oriented queries. It does not explicitly name alternative tools or exclusions, but the 'right now' framing and noticeability ranking provide clear context for when this tool is appropriate.

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