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

With only readOnlyHint and openWorldHint annotations, the description adds valuable behavioral context: rules are assessed under CAA class marks in force from 2026, with the EU C-class transition noted through end of 2027, and it states what the check returns. It stops short of describing edge cases like an unrecognized model with no weight supplied.

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

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

Three sentences, each with a distinct job: output summary, input invocation, and legal/date caveat. It is dense but not 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?

The description covers the essential decision-making context: what results to expect, how to identify the drone, and the legal regime/date sensitivity. It is slightly incomplete about behavior when conflicting or no identification inputs are provided, but the schema descriptions cover parameter-level details.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds slight extra meaning by naming the catalogue brands and by instructing that a weight plus class mark can substitute for a model lookup, but it does not need to re-document the parameters.

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

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

The description names the exact verb and resource: checking which UK open category rules apply to a consumer drone, and it enumerates the output categories (subcategory, separation, Flyer/Operator ID, Remote ID). This makes it distinct from the location, weather, preflight, and NOTAM 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 usage context is clear: it is for UK open category consumer drone rule questions, and no sibling tool overlaps with that function. It does not spell out exclusions such as non-UK or commercial operations, but the scenario is specific enough for an agent to route correctly.

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

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

Annotations already mark the tool as readOnly and openWorld, so the safety profile is covered. The description adds valuable behavioral context by detailing what the response contains (one-line verdict, zones with vertical limits, activation notes, contact, landowner rule) and explicitly excluding temporary restrictions. It does not go into rate limits or data source caveats, but the core behavior is well-disclosed.

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: scope, input method, output content, and exclusion with routing to the correct sibling. It opens with the primary purpose and ends with the key non-goal, with no filler or redundant restatement of the title.

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

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

Given there is no output schema, the description fully compensates by enumerating the return value structure. All parameters are documented in the schema, annotations cover side effects, and the sibling tool route is provided. Nothing needed for correct invocation 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 the schema already documents all five parameters. The description adds a small amount of guidance (place name or postcode, or lat/lon) and signals that the point is the subject of the check, but it does not substantially expand on the parameter meanings beyond what the schema already provides. 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 clearly states a specific verb and resource: check permanent UK airspace restrictions at a single point for drone flying. It explicitly distinguishes itself from the sibling check_notams by stating what it does not cover, so an agent can tell it apart without opening the schema.

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

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

It gives explicit input guidance ('Give a place name or postcode, or lat/lon') and states the exclusion condition ('Does not include NOTAMs') with the alternative tool to call instead ('call check_notams for temporary restrictions'). This is clear when-to-use and when-not-to-use guidance.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, but the description adds meaningful behavior: it states the tool is informational, not a substitute for official briefings, and that NOTAMs without usable coordinates are listed separately to avoid silently dropping them. This goes beyond the annotations and gives the agent a clearer sense of the tool's limitations and output handling.

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 (four sentences) and front-loaded with the core purpose, followed by key output details and a disclaimer. Every sentence adds value without redundancy or filler, making it efficient 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?

Given the tool has 7 parameters, no required ones, and no output schema, the description does a good job covering the main output aspects: it lists return fields (validity, radius, full text), explains sorting, handles coordinate-less NOTAMs, and describes the format parameter options. It does not mention the max_results default or pagination, but these are minor gaps and the description is adequate 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?

Schema description coverage is 86%, which is high, so the schema already documents most parameters. The description adds a little context, such as 'optionally within a radius and on a given date' mapping to radius_km and date, and explains the output is sorted by distance. However, it does not add significant new meaning beyond the schema, so it meets the baseline for high 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 states a specific verb ('Check') and resource ('temporary airspace restrictions (NOTAMs) from the NATS UK pre-flight bulletin'), with clear scope: covering a point, optionally within a radius and on a given date. It also specifies output characteristics (sorted by distance, coordinate-less NOTAMs listed separately), which distinguishes it from sibling tools like check_route or check_location without needing to open their schemas.

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

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

The description gives context that it is informational and not a substitute for an official NATS pre-flight briefing, which implies a limitation but does not explicitly state when to use this tool versus alternatives like preflight_briefing or check_route. It lacks explicit exclusions or comparative guidance, so an agent must infer the appropriate context.

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

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

Beyond the readOnlyHint/openWorldHint annotations, the description discloses the return shape (zones crossed, deduplicated, first-entry distance) and the geocoding behavior, including that ambiguous place names are returned for the agent to resolve. It also scopes itself to 'permanent' restrictions, an important behavioral boundary. No contradiction with annotations.

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

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

The description is three sentences with no wasted words: purpose, input requirements, and output/alternative behavior. It front-loads the most decision-relevant information and keeps the input format summary tight.

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 four parameters, no output schema, and rich structured parameter descriptions, the description provides what is missing: accepted input forms, geocoding edge behavior, the deduplicated return value, and a pointer to check_terrain. An agent has enough context to invoke 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?

The input schema already documents all parameters (100% coverage), so the baseline is a 3. The description adds practical meaning by explaining that place-name waypoints are geocoded and that ambiguous names are surfaced for resolution, plus the 'at least two' constraint. It does not duplicate schema field details, and the meaning it adds is genuinely useful.

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 specific verb and resource: 'Check permanent airspace restrictions along a drone route or across an area.' This immediately distinguishes the tool from siblings like check_terrain (elevation) and communicates the route/area scope. It is not a tautology and an agent can tell what it does without opening the schema.

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

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

The description gives clear usage instructions: provide at least two waypoints or an area, with accepted formats for each. It also names an alternative for a different need ('For ground elevation along the route call check_terrain'). However, it does not explicitly contrast with other relevant siblings such as check_notams or check_location, so the guidance is strong but not exhaustive.

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 indicate readOnlyHint=true and openWorldHint=true. The description goes beyond those by adding useful behavioral context: it discloses the geographic coverage limitation for rights-of-way data and the interpretive note that a public right of way is a strong indicator of legal access. No contradiction with annotations exists.

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 dense paragraph with no filler. Every clause earns its place: the core action, the list of returned categories, and the crucial coverage caveat about England and Wales. It is front-loaded with the main purpose and keeps the most important interpretive guidance at the end.

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

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

With no output schema, the description carries the burden of explaining return values, and it does so by listing all major result components: airspace verdict, public rights of way with distances, responsible council, landowner rules, open access land, and designations. It also covers a key limitation (data coverage) and a practical interpretation (RoW as legal access indicator). For a read-only assessment tool with 8 optional params, this is fully adequate.

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 all parameters are already documented in the input schema (lat/lon bounds, place examples, format enum, max_paths, a2_certificate, search_radius_m). The description adds some context around the returned data but does not enrich parameter meaning beyond the schema, so the baseline 3 applies.

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

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

The description opens with a specific verb and object: 'Assess a potential drone take-off spot in the UK.' It then enumerates the concrete outputs (airspace verdict, rights of way, council, landowner rules, designations), making the tool's function unmistakable and clearly distinct from siblings like check_drone_rules or check_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 conveys clear context for use by explaining that a public right of way is a strong indicator of legal access and noting that rights-of-way data covers England and Wales only. It does not explicitly name sibling alternatives or state when to use another tool, but the scope and limitations are clear enough for an agent to decide when this tool applies.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds valuable context: data source (Copernicus GLO-90 via Open-Meteo), resolution (~90 m), and what is reported (highest/lowest ground, warnings). This goes beyond the annotations without contradiction.

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 each sentence adds value: purpose, modes, output, and data source. It is front-loaded with the main rule and mode explanation, and avoids unnecessary 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?

Without an output schema, the description adequately describes the return content (highest/lowest ground, warnings) and the context of the rule. It does not cover error handling or edge cases, but for a read-only terrain tool, it is reasonably 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?

Schema coverage is 100% with per-parameter descriptions. The description enhances this by explaining the route vs. point distinction and how parameters like waypoints and radius_m are used. It also clarifies lat/lon vs. place usage, adding semantic value beyond the schema.

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 purpose: checking ground elevation against the 120 m rule, with two clear modes (route and point). It distinguishes itself from sibling tools like check_route or check_location by focusing on terrain elevation relative to flight height.

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 describes the two input modes (waypoints for profile, place/lat/lon for radius) and explains the context of the 120 m rule. It does not name alternative tools or exclusion criteria, but the usage context is clear and actionable.

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 it read-only and open-world; the description adds that it returns an hourly advisory rating (good/caution/poor), names the data source, and states the default time window. This goes beyond the structured hints 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?

Three sentences front-load the core data and rating, then give input instructions and defaults. No filler or repetition of schema details.

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 six parameters and no output schema, the description covers input selection, default behavior, and what the report contains (weather variables plus categorical rating). It doesn't state units or JSON shape, but the format parameter and schema fill most of the remaining 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?

All six parameters have schema descriptions (100% coverage), so the baseline is 3. The description adds meaningful aggregation by telling the agent to provide 'a place or lat/lon' and that the date defaults to the next few hours, clarifying the implicit location requirement not captured by optional fields.

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 specific outcome ('Drone-relevant weather forecast for a UK point') and enumerates the exact variables and the flyability rating. This clearly separates it from sibling check_* tools focused on NOTAMs, terrain, airspace, or rules.

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 actionable invocation guidance: supply a place or lat/lon and optionally a date or date-time, with a default of the next few hours. It does not explicitly name alternatives such as preflight_briefing for a full briefing, but the weather-specific context makes the intended use unmistakable.

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 annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds meaningful behavioral detail beyond that: results are sorted nearest first, sourced from OpenStreetMap, and limited to publicly accessible places unless include_private is set.

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 three tight sentences with no filler. It front-loads the core function, then covers input, output, and filtering behavior efficiently.

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

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

For a read-only lookup tool with rich schema documentation and no output schema, the description covers the essential facts: data source, geographic scope, input modes, output content, sorting, and the privacy filter. Minor gaps like error behavior or data freshness are not critical given the openWorldHint and readOnly annotations.

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 86%, so the schema already documents most parameters including lat/lon, place, format, include_private, and search_radius_m. The description summarizes the input options and output fields, adding a little useful framing, but does not need to compensate heavily for missing parameter documentation.

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: find car parks, laybys, and rest areas from OpenStreetMap near a UK point. It also lists the returned fields (name, type, distance, fee, access notes), making the tool's purpose unmistakable and distinct from sibling tools like find_takeoff_spots or geocode.

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 input guidance: use a place name, postcode, or lat/lon, and explains the public-access default with include_private as an override. It does not explicitly name alternatives or say when not to use this tool, so it falls just short of full usage-routing guidance.

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

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

Adds substantial behavioral detail beyond the readOnlyHint and openWorldHint annotations: excluded zone types, positive and negative scoring factors, output contents (best few with reasons and coordinates), map numbering, and the legal caveat about rights of way. No contradiction with annotations.

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

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

Four sentences, with the main purpose front-loaded in the first sentence. Every sentence contributes: criteria, scoring behavior, output and display, and legal context. No filler 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?

For a read-only suggestion tool with no output schema, the description covers purpose, exclusions, scoring logic, and return shape well enough to call it correctly. It leaves some details implicit, such as how a2_certificate influences scoring, but schema and annotations cover parameter and safety aspects.

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 high (~88%), so the schema already documents most parameters accurately. The description adds little parameter-specific meaning beyond the 'near a UK place' framing; notably, the undocumented max_results parameter is not explained in the description either.

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 ('Suggest'), resource ('take-off spots near a UK place'), and concrete criteria (public rights of way, parking, open access land). The focus on scored suggestions with exclusions clearly distinguishes it from siblings like check_takeoff_site and find_parking.

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 usage context is clearly implied: call this when the user wants suggested take-off spots near a UK location rather than a check on a specific site. However, it never explicitly names alternatives or states when not to use it, leaving the agent to infer the choice between this and check_takeoff_site or preflight_briefing.

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 read-only safety profile (readOnlyHint=true). The description adds useful behavioral context beyond annotations by stating that it returns 'up to ten candidates with source and confidence,' which signals that results may be ambiguous and includes provenance. No conflicting behavior is described.

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

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

Three sentences with no filler: the first states the core function, the second gives usage guidance, and the third describes the return shape. Every sentence earns its place and the most essential information is front-loaded.

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

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

Without an output schema, the description compensates by describing the return value ('up to ten candidates with source and confidence'). It also covers the main trigger case and the query types. Minor gaps like coordinate system or how limit interacts with results are not critical for a read-only tool, so the definition is nearly 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?

Schema coverage is 67%, so the baseline is 3. The description adds a little meaning by noting 'up to ten candidates,' which hints at the limit parameter, but it does not explain the format parameter or the query semantics beyond what the schema already states. It neither significantly boosts nor hurts parameter understanding.

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 ('Resolve'), a clear resource ('a UK place name, postcode or landmark'), and an outcome ('to coordinates'). It also differentiates from sibling tools by framing its role as a disambiguation step before checks, making its purpose distinct from the check-oriented 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?

It explicitly tells the agent when to use the tool: 'Use it to disambiguate before running a check when a name could match several places.' It does not name alternative tools or state explicit when-not-to-use conditions, but the context is clear enough to route an agent correctly.

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

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

Annotations already include readOnlyHint=true, and the description adds useful behavioral detail by enumerating the returned data: zone centre, approximate radius, bounding box, vertical limits, and contact, plus optional GeoJSON geometry. There is no contradiction with the annotations, and for a read-only lookup this is strong disclosure.

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. It front-loads the operation and scope, then summarizes the return content and the optional output format. The example is compact and directly useful.

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

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

With no output schema, the description usefully enumerates the returned fields and clarifies the optional geometry. Combined with the detailed input schema and readOnlyHint, an agent has what it needs to call the tool correctly. A minor gap is the lack of explicit when-to-use guidance relative to sibling tools.

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 all three parameters. The description contributes a useful example ('Bristol' or 'EGGD') and mentions the optional GeoJSON output, but it does not need to compensate for missing schema 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 opens with a specific verb and resource: 'Look up a UK aerodrome's flight restriction zone (FRZ)' and clearly states the accepted inputs, name or ICAO code. This distinguishes it from the sibling tools that cover NOTAMs, drone rules, weather, and other aviation lookups.

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 context is clear: this tool is for retrieving an aerodrome's FRZ data. However, the description does not explicitly state when to choose this tool over sibling tools such as check_notams or check_drone_rules, nor does it give any exclusions. The usage guidance is implied rather than stated.

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

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

Annotations already declare readOnlyHint=true, so the description's 'Report' aligns with that. It adds valuable context beyond annotations by detailing what the report covers (licences, attribution strings that must be shown to users, cache age), which informs the agent of expected content and any compliance obligations. No contradiction.

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, information-dense sentence that front-loads the core purpose ('Report the data behind this server') and then efficiently lists all key elements without redundancy. Every clause adds substance; no filler 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?

Given the absence of an output schema, the description compensates well by listing the major report categories. It does not specify the exact structure or return format, but the 'format' parameter controls that, and the listed items give the agent a solid expectation. Some minor gaps exist, such as error handling or size limits, but these are low-risk for a read-only status tool.

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

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

Schema coverage is 100% and the single parameter 'format' is fully documented with enum descriptions (text, json, brief) and a default. The tool description does not add any parameter-level information, but the schema already carries the full semantic burden, so a 3 baseline 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 clear, specific action: 'Report the data behind this server' and enumerates concrete content (airspace pack version, AIRAC dates, source fetch times, licences, NOTAM cache age, geocoding providers, runtime details, attribution strings). This distinguishes it functionally from siblings like check_weather or geocode, making its 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?

The description implies usage for data provenance and attribution queries but never explicitly states when to use this tool versus siblings. It does not mention alternatives or exclusions. The 'brief' format hint for voice conversations is a light usage clue, but overall guidance is only implied, not stated.

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

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

Annotations already declare readOnlyHint and openWorldHint. The description adds valuable behavior beyond that: unreadable live sources are reported as outages rather than assumed clear, and drone rules are only included when a drone is named. This is exactly the kind of non-obvious behavior an agent needs to know.

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 front-loads the status output and the list of inputs, and the second adds the outage policy and key invocation guidance. Every clause 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 an 11-parameter aggregate tool with no output schema, the description covers purpose, input selection, default behavior, and the shape of the result (GO/CAUTION/NO-GO with reasons). It does not spell out the full output structure, but the format parameter in the schema covers the text/json/brief variants, so the description is reasonably 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?

Schema coverage is 100%, so the baseline is 3. The description adds extra meaning: it explains the place-or-lat/lon choice, the default 3-hour window, and the condition for frz_permission. This goes beyond the schema's field-level descriptions and helps an agent select the right combination of parameters.

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: a one-shot pre-flight briefing with a GO, CAUTION or NO-GO status and reasons. It enumerates the data sources (airspace, NOTAMs, weather, geomagnetic, rights of way, parking, drone rules), which clearly distinguishes it from the single-purpose sibling tools like check_weather or check_notams.

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 invocation context: provide a UK place or lat/lon, set the date and hours for the flying window, and optionally set frz_permission when an aerodrome has agreed. It does not explicitly say 'use this instead of individual check tools', but the aggregate nature of the briefing makes that implicit, and no misleading exclusions are present.

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