Normativa española de drones con fuente y fecha por regla: pasajes citables, zonas UAS, requisitos.
Scored across 5 tools
Each tool targets a clearly distinct purpose: flight_requirements computes requirements for a specific flight, rules_catalogue exposes the full rule set, search_regulation retrieves literal regulatory passages, spots_near returns community knowledge, and uas_zones provides map polygons. The descriptions explicitly cross-reference each other to prevent misselection, leaving no meaningful overlap.
All names use consistent snake_case without mixing casing conventions. However, the internal pattern varies slightly (mostly noun phrases like flight_requirements, rules_catalogue, uas_zones, spots_near, but one verb-first name search_regulation), which is a minor deviation from a single predictable pattern.
Five tools is well-scoped for a drone-regulation server: one for computed requirements, one for the underlying catalogue, one for corpus search, one for community spots, and one for UAS zone geometry. Each earns its place without redundancy or thinness.
The regulatory surface is solid: requirement computation, full rule catalogue, source search, UAS zones, and community spots are covered. Minor operational gaps remain (NOTAM, weather, terrain, obstacles), but flight_requirements explicitly exposes them via `not_covered`, so agents can work around them and know the boundaries.
Calcula, con el motor determinista de Aerset, qué trámites exige la normativa para volar en un punto de España, en una fecha y con una aeronave concreta: qué régimen de la categoría abierta aplica por peso y marcado de clase, qué zonas UAS publica ENAIRE sobre el punto, qué espacios protegidos constan en MITECO y quién autoriza cada cosa, con el plazo que el catálogo atribuye a cada trámite. Cada línea nombra la autoridad que la exige y la fuente con su fecha de revisión. NO concede permisos, no tramita nada y no afirma que la operación pueda realizarse: el campo not_covered enumera las fuentes que esta respuesta no consulta (NOTAM, terreno, obstáculos, meteo). La decisión es del operador y se consulta con AESA. · Runs Aerset's deterministic permit engine over a point, a date and an aircraft in Spain and returns the requirement list: the open-category regime for that weight and class marking, the UAS zones ENAIRE publishes over the point, the protected areas MITECO records, and who demands each item with the lead time our catalogue attributes to it. It grants nothing and files nothing; not_covered names the sources it does not consult, and the decision stays with the operator and the authority.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | ||
| lon | Yes | ||
| date | No | ||
| night | No | ||
| environment | No | RURAL | |
| class_marking | No | ||
| drone_weight_g | No |
| Name | Required | Description |
|---|---|---|
| lat | No | |
| lon | No | |
| note | No | |
| zones | No | |
| regime | No | |
| covered | No | |
| for_date | No | |
| available | No | |
| checked_at | No | |
| disclaimer | No | |
| viewer_url | No | |
| attribution | No | |
| not_covered | No | |
| requirements | No | |
| protected_areas | No | |
| zones_available | No | |
| invalid_arguments | No | |
| judged_at_height_m | No | |
| protected_available | No | |
| nearest_aerodrome_km | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, openWorld, and idempotent, but the description adds substantial behavioral context: it is deterministic, grants nothing, files nothing, does not affirm the operation can be performed, and explicitly lists sources not consulted via the `not_covered` field (NOTAM, terrain, obstacles, meteo). It also notes that each output line names the authority and source with a review date.
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 Spanish version is long but front-loaded with purpose; the entire English translation duplicates that content with no added information. The bilingual redundancy wastes tokens and makes the definition inappropriately sized for an agent.
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 complex 7-parameter tool, the description covers purpose, limitations, output-field semantics, and annotations cover the safety profile; the output schema handles return values. Remaining gaps are parameter formats and sibling routing, but the core is complete enough to call 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?
With 0% schema description coverage across 7 parameters, the description partially compensates by explaining the conceptual roles of the point, date, aircraft, weight, and class marking. It says nothing about formats for lat/lon or date, and does not explain the `night` or `environment` parameters, leaving real gaps.
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 ('Calcula') and resource (trámites for flying at a point/date/aircraft), with clear scope. It does not explicitly differentiate itself from siblings like uas_zones or rules_catalogue, so an agent cannot tell when to prefer this composite tool over the raw-data 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 scenario is obvious from the description ('para volar en un punto de España, en una fecha y con una aeronave concreta'), implying when it should be used. However, it never names alternatives or states when NOT to use it; exclusions only concern its output ('NO concede permisos'), not tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Devuelve el catálogo completo de trámites que Aerset mantiene para volar un dron en España, regla a regla: su código, su título, la autoridad que la exige, las condiciones en las que aplica, el plazo que le atribuimos y si ese plazo está comprobado contra la fuente o no, más la URL de la fuente y la fecha en que se revisó. Es el conjunto sobre el que trabaja flight_requirements, publicado para poder citarlo entero. Una regla sin reviewed_at no dice nada, y con lead_time_verified: false el plazo NO está comprobado. · Returns Aerset's whole catalogue of Spanish drone paperwork, rule by rule: code, title, the authority that demands it, the conditions under which it applies, the lead time we attribute to it and whether that lead time has been checked against the source, plus the source URL and the review date. It is the set flight_requirements evaluates, published so it can be cited whole.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| note | No | |
| rules | No | |
| licence | No | |
| available | No | |
| checked_at | No | |
| disclaimer | No | |
| attribution | No | |
| licence_url | No | |
| reviewed_through | No | |
| invalid_arguments | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly/idempotent/openWorld, so the bar is lower. The description adds genuine data semantics beyond them: a rule without `reviewed_at` 'no dice nada', and `lead_time_verified: false` means the lead time is NOT verified — real interpretation guidance for a read tool. It does not discuss volume or citation format details.
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 and well-structured, but it is delivered twice in full Spanish and English, which roughly doubles length for no added information. Every Spanish sentence has a verbatim English counterpart, so a significant fraction of the text is redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be explained, yet the description still names the key fields and flags the two caveats (`reviewed_at`, `lead_time_verified`) that matter for correct interpretation. The sibling relationship is covered; volume or pagination of a full catalogue return is not mentioned.
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?
Zero parameters, so there is nothing to document and the baseline of 4 applies. The description instead spends its words on the fields the catalogue returns, which is the relevant substitute 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?
States a specific verb and resource ('Devuelve el catálogo completo de trámites') and enumerates the exact content of each rule. It explicitly differentiates itself from the sibling by naming `flight_requirements` and describing the relationship ('Es el conjunto sobre el que trabaja `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?
Positions itself relative to `flight_requirements` as the catalogue that tool evaluates, and states it is 'published so it can be cited whole' — a clear hint to use this when you need the full set rather than a per-flight evaluation. No explicit when-not-to-use or exclusion, so not a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Busca en el corpus normativo de drones de España: BOE, Reglamento (UE) 2019/947, guías de AESA y EASA, y MITECO. Devuelve PASAJES literales con el título del documento, su URL y su fecha — no un resumen y no una conclusión. Úsalo para citar la norma con su fuente y su fecha. Lo que no consta en estas fuentes se cita como «en nuestras fuentes no consta X», nunca como una ausencia en el mundo. Para saber qué trámites exige un vuelo concreto, usa flight_requirements. · Searches Aerset's sourced corpus of Spanish drone regulation and returns literal passages, each with its document title, URL and vintage. Retrieval only: nothing is summarised and no conclusion is drawn. Quote a passage with its source and its date; an absence from the corpus is an absence from our sources and says nothing about the world.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes |
| Name | Required | Description |
|---|---|---|
| note | No | |
| query | No | |
| passages | No | |
| available | No | |
| checked_at | No | |
| disclaimer | No | |
| attribution | No | |
| corpus_documents | No | |
| invalid_arguments | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover read-only/idempotent/open-world, but the description discloses the retrieval-only contract (nothing summarised, no conclusion), the shape of each returned passage (title, URL, date), and an important epistemic constraint about how to report absence from the corpus. That is substantial context beyond what the structured hints provide.
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?
Dense and front-loaded: purpose, retrieval contract, citation rule, and alternative are ordered well. The main inefficiency is the full Spanish/English duplication of every clause, which roughly doubles length, though it appears to be a deliberate bilingual accessibility choice rather than 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?
For a read-only search tool, the description covers what is searched, what is returned, and how results should be cited, and an output schema exists so return values need no further explanation. Nothing an agent needs in order to call this correctly is missing, aside from parameter-level detail captured elsewhere.
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% for both parameters: `query` and `limit` carry only titles and a default, with no description text. The description adds no meaning for either parameter (no query format, no expected phrasing, no effect of `limit`), so it fails to compensate for the coverage gap even though it has two parameters to support.
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?
Specific verb+resource: it names exactly what corpus is searched (BOE, Reglamento UE 2019/947, AESA/EASA guides, MITECO) and what is returned (literal passages with title, URL, date, not summaries). It also names the sibling `flight_requirements` and the scenario that selects it, so an agent can distinguish it from siblings without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use ("Úsalo para citar la norma con su fuente y su fecha") plus an explicit alternative with its triggering condition ("Para saber qué trámites exige un vuelo concreto, usa `flight_requirements`"). It additionally gives a citation-behaviour rule for absent results, which is operative guidance, not filler.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Busca puntos de vuelo cerca de una coordenada, de la comunidad de pilotos de Aerset: nombre, coordenada, tipo de dron al que va bien y la dificultad que se le comprobó, con la fecha de esa comprobación. Es conocimiento de la comunidad y NO una fuente oficial: dice adónde va la gente, no qué exige la norma. Que un punto figure aquí no dice nada sobre el espacio aéreo de hoy — la dificultad es la del día en que se comprobó y no se recalcula—, así que los trámites los contesta flight_requirements y la última palabra la tienen AESA y el visor oficial de ENAIRE. · Finds flying spots near a coordinate from Aerset's pilot community, with the difficulty each one was checked at and the date of that check. Community knowledge, not an official source: it says where people go and nothing about what the regulation demands. A spot appearing here says nothing about today's airspace — its difficulty is the day it was checked and is never recomputed — so ask flight_requirements for the paperwork, and the authority and ENAIRE's official viewer have the last word.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | ||
| lon | Yes | ||
| radius_km | No |
| Name | Required | Description |
|---|---|---|
| note | No | |
| spots | No | |
| available | No | |
| checked_at | No | |
| disclaimer | No | |
| note_on_verdicts | No | |
| invalid_arguments | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/openWorld, but the description adds non-obvious behavior the annotations cannot: difficulty is a static snapshot that is never recomputed, the data is community-sourced and not authoritative, and its presence implies nothing about current airspace or legality. That is exactly the caveat an agent needs to avoid misusing the result.
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?
Content is front-loaded and each caveat is relevant, but the whole description is duplicated verbatim in Spanish and English, doubling length without adding information. Roughly half the text is redundant for any single-language agent.
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?
An output schema exists, so return values need no explanation, and the description covers purpose, alternatives, and data-provenance caveats well. The only shortfall is the unaddressed radius/coordinate parameter semantics, which the schema leaves bare.
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% for three parameters, and the description only implies a proximity search around a coordinate. It gives no units, default, or meaning for radius_km and no range/format guidance for lat/lon, so it does not compensate for the undocumented 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?
States a specific verb and resource ('Busca puntos de vuelo cerca de una coordenada') and enumerates the returned fields (nombre, coordenada, tipo de dron, dificultad, fecha). It explicitly separates itself from the regulation tools, so an agent can distinguish it from siblings 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?
Gives explicit when-to-use (community knowledge of where people fly) and when-not (regulatory/airspace questions), and names the correct alternative: 'los trámites los contesta `flight_requirements`'. Routing is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Devuelve los polígonos de las zonas geográficas UAS que ENAIRE publica dentro de un rectángulo, con el tipo de cada una, sus límites vertical inferior y superior y la fecha en que ENAIRE la actualizó. Es la capa que pinta un mapa, no un veredicto sobre un punto: para eso está flight_requirements. Una lista vacía significa que la consulta a ENAIRE no devolvió ninguna zona para ese rectángulo, y available: false significa que no se pudo consultar — ni la una ni la otra describen el cielo. El visor oficial de ENAIRE tiene la última palabra. · Returns the UAS geographical zones ENAIRE publishes inside a bounding box, each with its kind, its vertical limits and ENAIRE's own update date. It is a map layer and not a verdict about a point. An empty list means our query to ENAIRE returned nothing for that rectangle; available: false means the query did not happen. ENAIRE's official viewer has the last word.
| Name | Required | Description | Default |
|---|---|---|---|
| bbox | Yes |
| Name | Required | Description |
|---|---|---|
| note | No | |
| zones | No | |
| available | No | |
| truncated | No | |
| checked_at | No | |
| disclaimer | No | |
| viewer_url | No | |
| attribution | No | |
| invalid_arguments | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds valuable behavioral context: an empty list means ENAIRE returned no zones for the rectangle, while `available: false` means the query did not happen, and both should not be read as a statement about the sky.
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 useful distinctions, but it is duplicated in Spanish and English. For an AI agent, the second language block repeats the same information and does not earn its place, reducing overall conciseness.
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?
An output schema exists, so return value structure need not be explained. The description covers purpose, sibling distinction, result interpretation, and source authority well, but because input schema coverage is 0%, the lack of `bbox` format details is a notable gap for the only required parameter.
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% parameter description coverage and only one `bbox` string parameter. The description mentions a rectangle/bounding box, which loosely maps to the parameter, but it does not specify coordinate order, format, delimiter, or expected syntax, leaving the agent unable to construct a valid value from the definition alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: returns UAS geographical zone polygons published by ENAIRE inside a bounding box, including kind, vertical limits, and update date. It explicitly distinguishes itself from the sibling `flight_requirements` by saying it is a map layer, not a point verdict.
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?
Names the alternative tool `flight_requirements` and the condition that selects it: point verdicts. It also explains the meaning of an empty list versus `available: false`, giving the agent clear operational context for interpreting results and avoiding misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
flight_requirementsrules_cataloguesearch_regulationspots_nearuas_zonesNormativa española de drones con fuente y fecha por regla: pasajes citables, zonas UAS, requisitos.
Subvenciones, licitaciones y boletines oficiales de España y Europa para tu IA. Gratis, sin login.
Jurisprudencia, normativa y doctrina oficiales españolas para abogados, con citas verificadas.
AI legal copilot for foreigners in Spain: immigration and housing rental, cited to Spanish law.
Add one secure layer between your agents and this server.
