open-transfer-times
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": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| check_connectionA | Assess whether a one-stop flight connection leaves enough time to transfer. Deducts the transfer steps that apply at the connection airport (walking, Schengen passport control, terminal change, security re-screening, baggage re-check) from the scheduled layover and returns comfortable / reasonable / tight / risky, the reasons, ticket-protection exposure, and the cited airport facts behind the estimate. Give the scheduled arrival and departure as local wall-clock times at the connection airport, or only layover_minutes when that is all the user said. Explain the result using the returned steps; airport facts are context and only apply where their scope matches the trip. |
| compare_connectionsA | Assess several one-stop itineraries (for example the results of a flight search) and rank them from safest to riskiest connection: by transfer quality, then ticket protection (one ticket before unknown before self-transfer), then confidence, then remaining margin. Each option takes times or layover_minutes, like check_connection. Use the optional id to map results back to your own options (e.g. an offer id or price). |
| get_airport_profileA | Return the transfer allowances used for an airport, whether each is a heuristic estimate or sourced, and the cited facts (with official source links) about transferring there. Airports without a profile use the standard baseline. |
| list_airportsA | List the airports that have their own transfer profile, with how well each is sourced. |
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 4 tools
Each tool targets a distinct operation: single-itinerary assessment (check_connection), multi-itinerary ranking (compare_connections), per-airport detail (get_airport_profile), and an index of profiled airports (list_airports). The descriptions explicitly relate compare_connections to check_connection ('like check_connection'), making the boundary between single and batch use clear.
All four names follow a consistent snake_case verb_noun pattern: check_connection, compare_connections, get_airport_profile, list_airports. The verbs (check/compare/get/list) accurately signal the differing semantics.
Four tools is well-scoped for a narrow domain of transfer-time evaluation; each tool covers a distinct need (assess one, rank many, inspect airport data, discover airport data). Nothing feels padded or missing at the surface level.
The surface covers the full workflow: evaluating a connection, ranking alternatives, and inspecting the underlying airport facts, with a stated baseline for unprofiled airports. Minor gap: no way to look up or search airports that lack a profile or to see the baseline allowances explicitly, which an agent may want when explaining results.