Precise scope and non-goals
What is the Model Context Protocol? must be understood as the protocol boundary between an AI host, one client connection and a server exposing tools, resources or prompts. 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 offer search, booking retrieval and disruption information backed by NDC, OpenTravel, GTFS or proprietary supplier systems. 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 confusing protocol interoperability with domain correctness, trusting server descriptions without approval, and exposing excessive data. 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 version negotiation, capability discovery, schema validation, source provenance and controlled negative tests. 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.
Answer first and a minimal travel tool
MCP standardisiert den Zugriff einer KI-Anwendung auf eine klar begrenzte Fähigkeit. Fachliche Wahrheit, Berechtigung und Transaktionssicherheit bleiben in den verantwortlichen Systemen.
Minimal travel tool
{
"name": "search_offers",
"description": "Sucht Reiseangebote; das Ergebnis ist keine Buchungsbestätigung.",
"inputSchema": {
"type": "object",
"properties": {
"destination": { "type": "string", "minLength": 2 },
"date_from": { "type": "string", "format": "date" },
"date_to": { "type": "string", "format": "date" },
"travellers": { "type": "integer", "minimum": 1 },
"max_price": { "type": "number", "exclusiveMinimum": 0 },
"currency": { "type": "string", "pattern": "^[A-Z]{3}$" }
},
"required": ["destination", "date_from", "date_to", "travellers"]
}
}MCP standardises interaction with a bounded capability. Domain truth, authorisation and transaction safety remain with the responsible systems. Production contracts add output schema, limits, stable errors and freshness.
Tools, resources and prompts compared
| Primitive | Auslösung | Geeignet für | Hauptkontrolle |
|---|---|---|---|
| Tool | Modell über Client | Suche, Berechnung, Zustandsänderung | Schema, Autorisierung, Zustimmung |
| Ressource | Anwendung | Adressierbarer Kontext | Lesezeit-Berechtigung, Aktualität |
| Prompt | Nutzer | Wiederverwendbare Vorlage | Transparenz; keine Systempolicy |
The primitives allocate control differently across user, application, model and server.
JSON-RPC from discovery to invocation
Discovery mit tools/list
{
"jsonrpc": "2.0", "id": 17, "method": "tools/list", "params": {}
}Aufruf mit tools/call
{
"jsonrpc": "2.0",
"id": 18,
"method": "tools/call",
"params": {
"name": "search_offers",
"arguments": {
"destination": "JP",
"date_from": "2026-09-10",
"date_to": "2026-09-20",
"travellers": 2,
"max_price": 4000,
"currency": "EUR"
}
}
}After initialisation and capability negotiation the client lists and invokes tools. The server still validates identity, object access and domain rules.
Connection lifecycle and negotiated behaviour
A connection starts with initialisation, protocol-version selection and capability negotiation. Normal operation begins only after the initialized notification. Neither side may assume optional behaviour that was not announced, and compatibility must be tested for each supported client and protocol baseline.
Discovery is a runtime contract. Names, descriptions and schemas influence model selection and therefore require version control, regression tests and a staged rollout. Shutdown also needs defined treatment of running calls and incomplete domain operations.
Responsibility boundaries
The host owns user interaction, model context, capability filtering and approval policy. A client maintains one protocol relationship to one server. The server describes and enforces its bounded capabilities, while a GDS, CRS, PMS, order platform or payment system usually remains authoritative for domain state.
This separation makes failures diagnosable: model selection, client policy, protocol processing, authorisation and supplier outcomes are different failure domains and require separate telemetry.
Errors and retry semantics
A production contract distinguishes invalid input, denied access, missing objects, domain conflicts, temporary dependency failure and internal defects. An expired offer is an expected domain conflict rather than an unknown server error.
Reads may be retried within limits. Writes require idempotency and authoritative reconciliation because a timeout can occur after the backend changed state. MCP does not create a distributed ACID transaction across suppliers.
When MCP is the appropriate abstraction
MCP is compelling when several AI hosts need the same curated capabilities, user intentions vary and one governed contract should describe discovery, inputs, outputs and side effects. A travel platform may expose offer search, repricing and order retrieval while keeping proprietary supplier APIs behind a stable domain boundary.
A direct API is often better for a known deterministic consumer and high-frequency machine traffic. A workflow engine is preferable when every step is rule-based and must be reproduced exactly. The decision should compare correctness, latency, operating cost, security boundaries and changeability for the same task rather than comparing protocol labels.
Travel-domain constraints
MCP does not create inventory, prices, fare rules or contractual validity. NDC, OpenTravel, GTFS and proprietary interfaces remain source contracts. Offer, order, PNR, reservation, ticket and itinerary are not synonyms; a server must preserve source namespace, identifier, version and authoritative status.
A search response carries provenance, retrieval time, currency, material inclusions and a validity boundary. Before commitment, the server revalidates price, inventory, identity and current object state. Any material change invalidates the earlier approval and requires a new decision tied to the exact terms.
Production acceptance evidence
Acceptance goes beyond a successful call. Tests cover version negotiation, capability changes, schema boundaries, inappropriate tool selection, denied identities, cross-object access, manipulated resources, result limits, timeouts and duplicate delivery. Travel cases add expired offers, repricing, partial confirmation and supplier failure after a write.
Metrics separate model, host policy, client, MCP server and system-of-record outcomes. Production release also requires named ownership, service objectives, telemetry, rollback, deprecation and a per-capability kill switch.
Where MCP stops
MCP does not define travel prices, fare rules or lawful processing. NDC, OpenTravel, GTFS and proprietary APIs remain domain source contracts.
A direct API remains preferable for many deterministic high-volume integrations.
A worked travel transaction from intent to evidence
Consider a traveller asking to exchange one flight in an existing trip. The host first establishes the authenticated user and the booking context, then exposes only the capabilities permitted for that role and object. A client discovers an exchange-quotation tool on the airline domain server. The server reads the authoritative order, applies fare and inventory rules through the supplier interface, and returns an expiring change offer with provenance, total difference and material conditions.
The model can explain that offer, but it cannot silently accept it. The host presents the exact itinerary, traveller, currency, price difference, refund or collection amount and expiry. After explicit approval, a separate execution tool validates identity, object ownership, offer version and current supplier state. An idempotency key prevents accidental duplication. The server then rereads the order, ticket and payment state and reports partial or pending results rather than converting technical success into a false confirmation.
What the protocol contract does and does not prove
A JSON Schema proves that a message has the expected structure; it does not prove that a traveller owns a booking, an offer is current or a supplier permits the requested action. Capability discovery proves that a server advertises an operation; it does not establish that the current principal may invoke it. OAuth authentication proves aspects of identity and token validity; it does not replace tenant, role, object and business-state authorization.
These distinctions are central to travel systems because commercial truth changes over time and is distributed across providers. A robust MCP design names the system of record for every consequential field, preserves source identifiers and timestamps, and defines which claims the host may make at each state. The protocol is the interaction layer; supplier contracts, travel standards, payment controls, privacy law and operating procedures remain independent obligations.
A defensible adoption test
Adopt MCP when several AI hosts need reusable, discoverable and governed capabilities, when user intentions vary, and when a shared capability contract reduces duplicated orchestration. Prefer a direct API for stable, deterministic, high-volume machine traffic, and prefer a workflow engine when the complete sequence must execute by fixed rules. Mixed architectures are normal: MCP can mediate user-driven decisions while APIs and event streams carry operational data.
The decision record should compare the same task across correctness, latency, cost, security boundary, changeability and recovery. A production claim requires negative authorization tests, stale-state tests, duplicate-delivery tests, supplier failure handling, observability and a safe rollback or kill switch. Registry presence, SDK compatibility or one successful demonstration is not sufficient evidence.
Primary sources and academic context
This page follows the versioned MCP specification and separates normative requirements from architectural recommendations.