Skip to main content
Glama

Consultar METAR, NOTAM o SIGMET de Ecuador

get_aviso_aeronautico
Read-only

Get live METAR, NOTAM, or SIGMET aeronautical notices for Ecuadorian airports by ICAO code. Returns raw ICAO text or JSON.

Instructions

Live aeronautical notices from DGAC/AIS: metar (latest weather reports) or notam (active notices) for an aerodrome ICAO code, e.g. SEQM; sigmet (active SIGMETs for the whole FIR, no code needed). Raw ICAO text.

Input Schema

NameRequiredDescriptionDefault
tipoYesmetar, notam or sigmet.
formatNotext summary (default) or json structured result.text
designadorNoICAO code of the aerodrome, e.g. SEQM (Quito), SEGU (Guayaquil), SECU (Cuenca).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.13.0
    • changedOutput schema / (root)
      Previous value: -{
      -  "additionalProperties": true,
      -  "type": "object"
      -}New value: +null
  2. Addedv0.11.0

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, non-destructive) and open-world scope. The description adds genuinely new context: the data is 'live', output is 'raw ICAO text', and sigmet needs no aerodrome code. It omits auth/permission needs and any rate-limit behavior.

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?

A single front-loaded sentence with zero filler; the tool's function, all three modes and the output format are conveyed compactly. The semicolon-joined parentheticals are dense and slightly hurt scanability, but nothing is redundant.

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

Completeness4/5

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

For a 3-parameter, no-output-schema tool with annotations covering safety, the description supplies the domain context, mode semantics and output nature an agent needs. Minor gaps: how the json format option differs from 'raw ICAO text', and behavior on an invalid or empty ICAO code.

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 coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by tying 'designador' to the metar/notam modes and clarifying that sigmet does not need a code, resolving the conditional applicability of a parameter the schema only presents as an empty default.

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?

Names a specific verb+resource (live aeronautical notices from DGAC/AIS) and enumerates the three products it returns (metar, notam, sigmet) with what each contains. The scope statement for sigmet ('whole FIR, no code needed') vs the ICAO-code scoping for metar/notam makes it clearly distinct from aerodrome-data siblings like get_aip_aerodromo.

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?

Gives clear selection context per mode: metar for latest weather reports, notam for active notices, sigmet for FIR-wide alerts requiring no code. It stops short of naming alternative siblings (e.g. the AIP aerodrome tools) or stating when not to use it.

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

Deploy Server

Other Tools