FACT COPY · EN
Fact copy: MCP compared with traditional APIs
How MCP and existing REST, GraphQL and enterprise APIs differ and work together.
Canonical source: https://travel-mcp.com/en/mcp-vs-api/
Factual summary
How MCP and existing REST, GraphQL and enterprise APIs differ and work together.
Precise scope and non-goals
MCP compared with traditional APIs must be understood as different abstraction levels: APIs expose application contracts while MCP standardizes capability discovery and invocation for AI hosts. MCP does not supply inventory, commercial rules, traveller consent, settlement logic or the truth of a booking. Those responsibilities remain with the application and its systems of record.
A useful architecture therefore starts with the user task and authoritative data path, not with a list of SDK features. The protocol contract is valuable only when it preserves the domain contract behind it.
Protocol behaviour and responsibility
A connection starts with initialization, protocol-version negotiation and capability negotiation. Optional features must be detected at runtime and recorded in a compatibility matrix; clients and servers cannot assume that every peer implements the same capability set.
Tool and resource schemas validate structure, not business truth. The server still enforces authorization, object ownership, tenant boundaries, freshness and downstream preconditions. Results remain untrusted input to the host and model.
Travel architecture example
A concrete application is an MCP server curating task-level operations over REST, GraphQL, SOAP, NDC, OpenTravel or proprietary supplier interfaces. Every result should preserve source, retrieval time, currency and material conditions; a time-limited offer must not be presented as confirmed inventory.
Binding operations require a fresh state check, explicit presentation of the material change, an approval bound to those exact parameters and idempotent execution. PNR, ticket, EMD, order and itinerary are not interchangeable records.
Failure modes and security boundary
The principal failure modes are replacing stable deterministic integrations without benefit, flattening domain errors and assuming MCP supplies travel semantics. These are architecture defects, not problems that can be delegated to prompt wording or model judgement.
Controls belong at independently enforceable boundaries: the host limits exposure and obtains approval, the MCP server validates the request and identity, and the downstream system rechecks domain rights and state. Each layer must fail closed for operations it cannot establish safely.
Evidence for production use
Production readiness requires a documented decision matrix, preserved error and concurrency semantics, measured tool-selection value and total operating cost. A successful demonstration proves only that one path worked once; it does not establish compatibility, security, recovery or domain correctness.
Evaluation should separate model-selection errors, client policy failures, MCP server failures and supplier-system conflicts. Measures include task correctness, inappropriate calls, user corrections, stale-state rejection, latency, cost per successful outcome and recovery time.