MCP reference

The Movmo MCP server exposes the same handlers as REST through the Model Context Protocol. Use it from any MCP-aware client (Claude Desktop, Cursor, ChatGPT connectors, custom agents).

Transport

• stdio — for local agent hosts. The movmo-mcp binary spawns per user; auth flows through OAuth PKCE against auth.e2e.movmo.io (pre-prod; prod alias is auth.movmo.io).
• Streamable HTTP at https://e2e.api.movmo.io/v1/mcp — for remote MCP clients. Stateless Bearer auth: the client sends an OAuth access token on every request; no server-side token storage.

Both transports support OAuth discovery (RFC 9728 /.well-known/oauth-protected-resource and RFC 8414 /.well-known/oauth-authorization-server) and Dynamic Client Registration (RFC 7591) for autonomous agents. Pre-registered partners use the same OAuth flow as REST — see Authentication.

Scopes

Agent tokens follow the same scopes and consent model as REST, and for agents it is not optional: both discovery documents advertise the full ten-scope Movmo catalog in scopes_supported, and a dynamically-registered client that omits scope (or sends only the OIDC identity scopes) is treated as requesting all ten. Either way the user grants the permissions on the Movmo consent screen during authorization, the token response echoes the effective scope, and tool calls outside the granted scopes fail with insufficient_scope — the error names the missing scope so the agent can re-authorize for the delta. Agents that only need a subset (say, read-only trip lookups) should request it explicitly: the consent screen is shorter and the token is least-privilege.

Consent is granular on the Movmo side, so an agent asking for all ten scopes (or any subset) may still come back with fewer than it requested — the user can untick individual permissions on the consent screen, and a previously-declined scope is never re-offered. Treat this as a normal, per-tool condition rather than a fatal error: a tool call that needs a scope the user withheld fails with insufficient_scope, so disable or skip that specific tool for the session instead of failing the whole conversation, and let the user know they can grant the missing permission later from Connected apps in their Movmo account without reinstalling or reconnecting the agent.

Tool list

The deployed tools are documented inline in each domain page:

• Profile — get_user_profile, get_travel_preferences, get_locale_preferences
• Passengers — get_passengers_profile, create_passenger_profile, update_passenger_profile, delete_passenger_profile
• Payments — get_payment_methods, update_payment_method, delete_payment_method
• Flights — search_flights, create_offer, get_offer_details, get_seat_map, get_bags, update_passenger, create_booking, get_booking

The server also registers two semantic-discovery tools (list_semantic_resources and read_semantic_resource) used by agents to retrieve plain-text booking guides, provider notes, and error references at runtime. They will appear in any tools/list response.

A consolidated tool reference with full input schemas is on the roadmap. Today, an MCP client discovers schemas via the standard tools/list call against the running server.