Skip to main content
Glama

Hora local de salida y de llegada

airport-local-times
Read-onlyIdempotent

Convierte una hora de salida en un aeropuerto (instante ISO u hora local allí) a la hora local, desfase UTC y día de la semana en ese aeropuerto y, opcionalmente, en el de llegada tras una duración de vuelo, con la zona IANA derivada de cada aeropuerto. Cuándo: hay que mostrar una hora de salida como hora local en los aeropuertos de salida y llegada, o calcular la hora local de llegada con la duración del vuelo. No para: devolver la fecha, la hora local, el desfase UTC y si rige el horario de verano en una ciudad dada por nombre (city-local-time). Efectos secundarios: ninguno (solo lectura, sin red, sin estado guardado). Determinista: la misma entrada da la misma salida. Límites: entrada JSON de hasta 64 KB, 1 s por llamada, resultado de hasta 1 MB.

EN: Converts a departure time at one airport (ISO instant, or local time there) to the local wall-clock time, UTC offset and weekday at that airport and, optionally, at an arrival airport after a flight duration,… [EN completo / full EN: inputSchema.description]

Example tool call

This call uses example arguments supplied in the tool’s input schema.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "at": "2026-11-03T22:10",
      "to": "MAD",
      "from": "BOG",
      "duration_minutes": 590
    },
    "name": "airport-local-times"
  }
}

Input Schema

NameRequiredDescriptionDefault
atYesDeparture time: ISO 8601 with Z/offset, or local time at the departure airport (2026-11-03T08:30) (string; required; at least 10 chars; up to 40 chars).
toNoArrival airport (optional): IATA code (BOG), ICAO code (SKBO), OurAirports ident, or part of the airport name or city (El Dorado, Medellín) (string; optional; at least 2 chars; up to 100 chars).
fromYesDeparture airport: IATA code (BOG), ICAO code (SKBO), OurAirports ident, or part of the airport name or city (El Dorado, Medellín) (string; required; at least 2 chars; up to 100 chars).
duration_minutesNoFlight duration in minutes, to compute the arrival time (integer; optional; min 0; max 10080).

Output Schema

NameRequiredDescriptionDefault
sourceNo
arrivalNo
ambiguousNo
departureNo
arrival_utcNo
departure_utcNo
other_matchesNo
duration_minutesNo
at_interpreted_asNo
arrival_day_offsetNo
arrival_offset_difference_minutesNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the description's 'sin red, sin estado guardado' largely restates them. It does add genuinely new behavior: deterministic output for identical input, and concrete limits (64 KB JSON input, 1 s per call, 1 MB result), which help the agent size requests.

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

Conciseness3/5

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

Labeled sections (Cuándo / No para / Efectos secundarios / Determinista / Límites) front-load the purpose well and every label is scannable. However, the Spanish and English versions duplicate the same content wholesale, and the trailing '… [EN completo / full EN: inputSchema.description]' is a truncation artifact that wastes space without adding information.

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?

An output schema exists, so return values need no explanation, and the description covers the remaining agent-relevant concerns: input formats, optional arrival computation, deterministic behavior, resource limits, and the sibling it must not be confused with. Nothing needed to call it correctly is missing.

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

Parameters3/5

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

Schema description coverage is 100% and each parameter already documents accepted formats (IATA/ICAO/ident/name substring, ISO or local time, duration bounds). The description only restates that duration yields the arrival time and that zones are derived per airport, adding no syntax or edge-case meaning beyond the schema. Baseline 3 applies.

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?

States a specific verb and resource chain: converts a departure time at an airport into local wall-clock time, UTC offset and weekday there, and optionally at the arrival airport after a flight duration. It also names the sibling it is not (city-local-time), so the agent can separate the two without opening either schema.

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

Usage Guidelines5/5

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

An explicit 'Cuándo' clause gives the triggering scenario (showing a departure time as local time at both airports, or computing arrival local time from a duration) and an explicit 'No para' clause routes the city-name case to city-local-time. When-to-use, when-not-to-use and the alternative are all present.

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