LOWLEVEL · normativa de drones en España

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

The description goes well beyond the annotations (readOnlyHint=true, openWorldHint=true, idempotentHint=true). It explicitly states the engine is deterministic ('motor determinista'), that it grants nothing and files nothing (reinforcing readOnly), and that the not_covered field lists sources it does not consult (reinforcing openWorld). This adds rich behavioral context that annotations alone do not provide, such as the fact that the decision rests with the operator and AESA. 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 long and bilingual, but every sentence earns its place: it explains the engine, the sources, the output, the limitations, and the decision responsibility. The core purpose is front-loaded, and the rest provides necessary behavioral context. While it could be tightened, the length is justified for a tool with 7 parameters and multiple data sources.

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

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

Given the tool's complexity (7 parameters, multiple data sources, an output schema), the description is remarkably complete. It explains what the output list contains (each line names authority and source with revision date), what the not_covered field does, and the fact that no permission is granted. Since an output schema exists, the description need not detail return values, and it covers everything an agent needs to correctly select and invoke the tool.

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

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

Schema description coverage is 0%, so the description must compensate. It does map several key parameters: 'punto de España' (lat/lon), 'fecha' (date), 'peso y marcado de clase' (drone_weight_g and class_marking), and 'aeronave concreta' (aircraft). However, it does not explicitly mention the 'night' or 'environment' parameters, though these are implied by context. Given the 0% coverage, the description covers most but not all parameters, earning a 4.

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

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

The description clearly states the tool's function: it runs a deterministic permit engine to calculate which requirements apply for flying a drone at a specific point in Spain, on a date, with a specific aircraft. It names the data sources (ENAIRE, MITECO, AESA) and the output (list of requirements with authorities and lead times). This is a specific verb+resource+scope that distinguishes it from siblings like uas_zones or rules_catalogue.

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 comprehensive requirement list) and explicitly states what it does NOT do (grants no permissions, does not file anything). It also names sources it does not consult (NOTAM, terrain, obstacles, meteo) via the not_covered field, which helps an agent understand limitations. However, it does not explicitly name alternative tools or provide 'use this instead of X when...' guidance, so it falls short of a 5.

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, openWorldHint, and idempotentHint. The description adds valuable interpretation caveats beyond those: a rule without `reviewed_at` is meaningless, and `lead_time_verified: false` means the lead time is NOT verified. This tells the agent how to interpret results, not just what the tool does.

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 content is front-loaded with purpose and fields, then the sibling relationship, then the data caveats. However, it is bilingual and repeats most of the first two sentences in English, adding length without new information; it remains structured and free of filler.

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

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

For a parameterless, read-only catalogue tool with an output schema, the description covers purpose, contents, its relationship to `flight_requirements`, and key interpretation caveats. Nothing needed to invoke or understand the result set is missing.

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

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

The tool takes zero parameters, and the input schema correctly reflects that with an empty properties object. With no parameters, the baseline is 4, and the description appropriately focuses on output semantics rather than arguments.

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 ('Devuelve'/'Returns') and the exact resource: LOWLEVEL's complete catalogue of Spanish drone paperwork. It enumerates the fields returned and explicitly distinguishes itself from sibling `flight_requirements` by stating it is the set that tool evaluates, published for whole-catalogue citation.

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 context: this is the dataset behind `flight_requirements` and is meant for citing the full set, implying use when the whole catalogue is needed rather than per-case evaluation. However, it does not explicitly state when not to use it or name `search_regulation` for filtered lookups, so it lacks full exclusion 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 provide readOnlyHint, openWorldHint, and idempotentHint, and the description adds consistent behavioral detail: 'Retrieval only: nothing is summarised and no conclusion is drawn', plus the important epistemic caveat about absences. This goes well beyond the annotations and directly shapes agent expectations.

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

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

The description is front-loaded with the core scope and return format, and it is well structured across scope, behavior, usage caveat, and sibling-tool routing. However, the Spanish and English versions repeat the same content nearly verbatim, adding length without new 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 search tool with an output schema and strong annotations, this description is complete: it names the corpus sources, the return fields, the absence semantics, the no-summary behavior, and the sibling tool for the next step. 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 0%, so the description must compensate for parameter meaning. It clearly explains what a query against the corpus should be, but it does not describe the `limit` parameter at all beyond its schema default, leaving pagination/result-count behavior implicit.

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 precise verb and resource: 'Busca en el corpus normativo de drones de España' and specifies the concrete sources (BOE, EU 2019/947, AESA/EASA, MITECO). It also distinguishes itself by saying it returns literal passages with title, URL, and date, not a summary or conclusion, and explicitly contrasts itself with flight_requirements.

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 guidance on when to use the tool: to cite a norm with its source and date. It also gives an exclusion: for concrete flight procedures, use flight_requirements insteadaging, and it states the open-world caveat that absence from the corpus is not absence in the world.

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, and idempotentHint annotations, the description discloses non-obvious behavioral traits: data is community-sourced not official, difficulty is stale once checked and never recalculated, and a spot's presence says nothing about today's airspace. These caveats add real safety-relevant context.

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

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

The bilingual text is longer than typical, but nearly every sentence adds substance: purpose, output fields, data provenance, freshness limitations, and sibling routing. The core action is front-loaded and the repeated official-vs-community caveat earns its place given the safety context.

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 community lookup with rich annotations and an output schema, the description is remarkably complete: it covers what is returned, where the data comes from, why the data may be outdated, and which sibling tool covers official requirements. The only minor omission is radius_km detail, which is a small gap against otherwise comprehensive coverage.

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 only mentions 'near a coordinate' without explaining coordinate format, units, or the optional radius_km parameter. While lat/lon are self-evident from the schema titles, the description adds no meaningful parameter semantics for radius_km.

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 a specific action ('Busca ... puntos de vuelo cerca de una coordenada'), the exact resource (LOWLEVEL pilot community), and the result fields (name, coordinate, drone type, difficulty, check date). It also differentiates itself from the regulatory sibling flight_requirements by explicitly stating it is unofficial community knowledge.

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 states when this tool is relevant (community flying spots) and when it is not (official regulation or current airspace). It explicitly directs the user to flight_requirements for paperwork and names ENAIRE/AESA as final authorities, which is strong alternative routing.

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

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

Beyond the annotations (readOnly, openWorld, idempotent), the description adds crucial behavioral context: it clarifies that an empty list means the query returned no zones, while `available: false` means the query did not execute, and it warns that ENAIRE's official viewer is authoritative. This goes well beyond the structured hints.

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 longer than average due to bilingual repetition, but it is well-structured: the first sentence states the core function, the second disambiguates from a sibling, the third explains result semantics, and the fourth adds authority. Every sentence adds value, though the dual-language duplication could be considered slightly verbose.

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

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

The tool is relatively simple with one parameter and an output schema (presumably covering return structure). The description covers purpose, alternatives, edge-case interpretation, and authority. The only missing piece is the precise format of `bbox`, which is not provided in the schema or description, so the description is not fully 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?

With schema description coverage at 0% for the single `bbox` parameter, the description must compensate. It mentions 'rectángulo' (rectangle) and 'bounding box', giving the conceptual meaning, but it does not specify the exact format (e.g., coordinate order, projection, delimiter). This is a minor but real gap for a tool with only one parameter.

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

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

The description explicitly states the tool returns UAS zone polygons within a bounding box, including type, vertical limits, and update date. It also clearly differentiates itself from `flight_requirements` as a map layer rather than a point verdict, making its purpose unambiguous and distinct from siblings.

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 provides explicit usage guidance: 'Es la capa que pinta un mapa, no un veredicto sobre un punto: para eso está `flight_requirements`' directly points to the alternative for point-based queries. It also explains how to interpret empty lists versus `available: false`, which is critical for correct usage.

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