flight_statusLlegadas y salidas del aeropuerto Alicante-Elche (ALC) para una ciudad o fecha concreta, con estado y hora publicada. Acota por ciudad o fecha en lugar de pedir el listado completo del día.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | Ciudad de origen o destino. | |
| date | No | Fecha YYYY-MM-DD en Europe/Madrid. | |
| type | Yes | Llegadas, salidas o todos los vuelos del día. | |
| limit | No | Resultados (máx. 10). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering safety and repeatability. The description adds that it returns status and published time, providing useful return-context. However, it does not detail pagination, error behavior, or data source, which is acceptable given the annotation coverage. Description does not contradict annotations.
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 two sentences, front-loaded with the main action and scope, and has no unnecessary words. It efficiently communicates the purpose and filtering guidance.
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 simple read-only tool with well-described parameters and helpful annotations, the description is complete enough. It mentions the key output (status and time), and the schema covers input details. No output schema exists, but the description offers a basic return hint. Given the overall simplicity, no critical information 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 100%, so each parameter (city, date, type, limit) already has a description. The tool description reinforces that city and date are filters, but adds little beyond the schema. Baseline 3 is appropriate because the schema handles the semantic burden.
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 lists arrivals and departures for Alicante-Elche airport, filtered by city or date, and includes status and published time. It explicitly distinguishes itself from requesting the full day list, so an agent understands its specific scope.
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 clear context on when to use this tool: when you need flights for a specific city or date rather than the complete day's list. It does not name an alternative tool explicitly, but the distinction from a full-day list implies when not to use it. No explicit exclusions are provided, but the guidance is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Most tools map cleanly to distinct domains (beach, fuel, weather, events, flights), but several transit tools overlap: find_transit_stop, favorite_stop, next_departures, get_current_state, and resolve_entity all deal with finding stops/stations and/or retrieving arrivals. Descriptions provide flow hints, so an agent can often disambiguate, but the boundaries are not crisp.
Names mix verb-led patterns (find_*, resolve_entity, get_current_state) with noun-led patterns (beach_conditions, fuel_prices, parking_availability) and oddities like favorite_stop and whats_on. The style is readable and mostly snake_case, but there is no consistent verb_noun convention.
16 tools is at the heavy end, and the travel-info surface could be consolidated (e.g., favorite_stop vs next_departures vs get_current_state). That said, Alicante's broad scope—transit, parking, beaches, food, weather, fuel, flights, events—makes the count defensible.
The set gives agents discovery (search_alicante, discover_capabilities), entity resolution (resolve_entity), and live/catalog state across transport, parking, beaches, weather, fuel, food, POIs, and events. Minor gaps exist (no general route planning, no editing/persistence beyond 'favorite'), but core informational workflows are well covered.