air_choose
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| AIR_CHOOSE_INTERVAL_MS | No | Optional override for the check interval in milliseconds. Default is 3600000 (1 hour). | 3600000 |
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": true
} |
| logging | {} |
| resources | {
"subscribe": true,
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_providersA | List every provider air_choose can query, with its coverage region and whether it needs a live browser session (those are NOT included here — only providers that work with plain HTTP calls are). |
| resolve_locationA | Every provider uses its own internal airport/city/country codes — you cannot just pass a Russian or English place name straight into a search. Call this FIRST for both the origin and the destination before add_watch, so you can see what each provider actually understood the place as. Accepts a country name (RU or EN, e.g. "Таиланд" / "Thailand"), a 3-letter IATA code (e.g. "BKK"), or a handful of built-in city aliases (Moscow, London, Singapore, Delhi, ...). Returns, per provider, the list of matched airports/cities/country codes — an empty list for a provider means that provider does not serve that place at all (e.g. Ryanair has no Moscow routes), which is normal, not an error. |
| add_watchA | Add a route to monitor. originQuery/destinationQuery go through the same resolution as resolve_location for every requested provider, immediately, and the watch stores each provider’s resolved codes — you get that resolution back in the response so you can sanity-check it before relying on the watch. An immediate first check runs right away (you do not have to wait for the hourly cycle to get initial results) and its offers are returned too. |
| remove_watchA | Stop monitoring a route and forget its price history. |
| list_watchesA | List every currently watched route, with when it was last checked and how many offers it has. |
| get_watch_offersB | Return the latest known offers for a watch, from the most recent check (hourly, or forced). |
| poll_new_offersA | Return every offer discovered since the last time this was called — new routes/dates appearing, or a price drop below the previously-seen best price — across ALL watches, and clears the queue. This is the reliable way to find out "what changed": call it on your own schedule (e.g. once an hour) rather than relying on push notifications, since not every MCP host wakes an idle agent on server notifications. |
| force_checkB | Re-run the fare check for one watch right now, instead of waiting for the hourly cycle. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| pending-offers | Offers found since the last poll_new_offers call (new routes/dates, or price drops). |
TDQS
Scored across 8 tools
Each tool targets a distinct action: add_watch, force_check, get_watch_offers, list_watches, remove_watch all operate on watches but with different operations; list_providers, poll_new_offers, and resolve_location are entirely separate concerns. No overlapping purposes.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., add_watch, list_providers, resolve_location). The naming is predictable and clear throughout.
8 tools is appropriate for an airfare monitoring server. It covers all necessary operations without being bloated or too sparse.
The toolset covers the full lifecycle of watch management (create, read, delete, force check) plus location resolution and provider listing. A minor gap is the lack of an update watch functionality, but this is not critical for the core use case.