flights-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| search_flightsA | Search live public Google Flights fares across a short date window. origin and destination take an IATA code or a city name. Defaults are 1 adult, economy, CHF. A planner can ask for one day, a few days around that day, or a from/to window such as a week. The price is the integer Google returned. This tool does not invent a fare, a flight number, or a bag rule. |
| resolve_airportsA | Resolve a city or airport name to IATA codes, offline. Zurich resolves to ZRH. Barcelona resolves to BCN. A metro code such as NYC returns that city code and its airports. The lookup does not use the network. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 2 tools
search_flights and resolve_airports have entirely distinct purposes: one performs live fare lookups, the other does offline name-to-IATA resolution. There is no overlap in intent, so an agent can select correctly without hesitation.
Both names follow a clean verb_noun snake_case pattern (search_flights, resolve_airports). The convention is predictable and consistent throughout the two-tool surface.
Two tools is thin for a flight-search domain; resolve_airports is really a supporting lookup rather than a peer operation. It is not wrong, but the surface feels minimal and could reasonably include one or two more operations.
The stated purpose is read-only fare search, and the pair covers lookup plus resolution with no dead ends for that scope. Minor gaps exist (e.g. no explicit round-trip or multi-passenger handling surfaced as separate operations), but agents can work around them.