Skip to main content
Glama

LOWLEVEL · normativa de drones en España

Trámites que exige un vuelo

flight_requirements
Read-onlyIdempotent

Calcula, con el motor determinista de LOWLEVEL, 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 LOWLEVEL'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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
latYes
lonYes
dateNo
nightNo
environmentNoRURAL
class_markingNo
drone_weight_gNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
latNo
lonNo
noteNo
zonesNo
regimeNo
coveredNo
for_dateNo
availableNo
checked_atNo
disclaimerNoOrientación con fuentes, no autorización. LOWLEVEL no concede permisos ni los tramita. La última palabra la tienen AESA y el visor oficial de ENAIRE, y cada decisión operativa se consulta con la autoridad antes del vuelo.
viewer_urlNo
attributionNoFuentes: BOE, Reglamento (UE) 2019/947, guías de AESA y EASA, ENAIRE (servAIS, ED-318) y MITECO/IEPNB. Cada pasaje y cada regla lleva la suya con su fecha.
not_coveredNo
requirementsNo
protected_areasNo
zones_availableNo
invalid_argumentsNo
judged_at_height_mNo
protected_availableNo
nearest_aerodrome_kmNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources