Travel Planning MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| TRAVEL_API_KEY | No | Bearer credential for travel API access. Becomes mandatory when binding to a non-loopback host. | |
| APPROVAL_API_KEY | No | Separate operator credential for approve/reject/apply/rollback REST calls. Should never be given to an ordinary AI client. | |
| ENABLE_ADMIN_MCP_WRITES | No | Enables MCP rollback only when explicitly set to 'true'. | false |
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 |
|---|---|
| get_provider_statusA | Describe the configured place and route providers so AI clients can distinguish demo estimates from live data. |
| list_tripsA | List canonical trips visible to the configured store. Returns lightweight trip summaries only. |
| get_tripA | Read the canonical trip and available version numbers. This tool never mutates trip state. |
| get_trip_contextC | Read an AI-friendly aggregate containing the trip plus referenced places, reservations, constraints, and available versions. |
| get_placeC | Read one normalized place through the configured PlaceProvider. |
| search_placesC | Search the configured PlaceProvider. Provider metadata is included so clients can distinguish demo vs live data. |
| get_reservationB | Read a reservation. Confirmed fixed reservations are protected from direct AI mutation. |
| get_constraintsA | Read all hard and soft constraints attached to a trip. |
| get_trip_auditA | Read the in-memory audit trail for proposal validation, approval, application, rejection, and rollback events. |
| calculate_routeA | Calculate a route through the configured RouteProvider. Provider metadata/source must be inspected before treating the result as live data. |
| create_change_proposalA | Create an auditable draft proposal against the current trip version. This does not modify the canonical trip. |
| validate_change_proposalA | Simulate and validate a proposal against version conflicts, schedule overlaps, locked/fixed items, and supported constraints. |
| get_change_proposalC | Read one proposal, impact estimate, approval receipt, and validation status. |
| apply_change_proposalA | Apply a successfully validated proposal only after an external human-controlled surface has attached an explicit approval receipt. This MCP server cannot approve proposals. |
| rollback_tripD | Administrative rollback. Disabled by default. Operators must explicitly enable admin MCP writes in the server environment. |
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 15 tools
Most tools cleanly map to distinct resources or actions, and the get_* read tools are generally easy to separate. get_trip_context intentionally overlaps with get_trip/get_place/get_reservation/get_constraints as an aggregate view, but its description clarifies that distinction.
Tool names consistently follow a snake_case verb_noun pattern: get_, list_, search_, calculate_, validate_, create_, apply_, rollback_. The change-proposal family is especially predictable because every stage uses the same verb-first structure.
At 15 tools, the set sits comfortably within the ideal range and each tool earns its place: reads, search, route calculation, proposal lifecycle, audit, and admin rollback are all represented. There is no obvious bloat or redundancy.
The surface covers trip/place/reservation/constraint reads plus a full validate-create-apply proposal workflow, audit trail, and rollback capability. Minor gaps exist around listing, updating, or deleting change proposals, but the core planning workflow is well supported and the mutation restrictions appear intentional.