Fact copy: MCP servers

Factual summary

Responsibilities, development, security and operation of MCP servers.

Precise scope and non-goals

MCP servers must be understood as a domain-owned capability service that validates protocol messages and mediates access to downstream systems. 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 bounded tools for offer retrieval, repricing, booking status or document access without publishing an entire GDS, PMS or CRS surface. 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 one-to-one endpoint conversion, ambiguous side effects, token passthrough, uncontrolled result size and missing recovery behaviour. 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 lifecycle and conformance tests, versioned contracts, backend-failure tests, telemetry, rollback and per-tool kill switches. 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.

Reference artefact: tool contract and invocation

{
  "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"]
  }
}

{
  "jsonrpc": "2.0", "id": 17, "method": "tools/list", "params": {}
}

{
  "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"
    }
  }
}

A testable contract combines description, schema, result limits, stable errors, authorisation and side effects.

stdio or Streamable HTTP?

Transport changes identity boundaries, attack surface, session design and scaling. A local subprocess inherits filesystem and environment permissions; a shared remote service requires HTTPS, Origin validation, OAuth, tenant isolation and explicit session handling.

Lifecycle and capability negotiation

The server does not begin normal operation before initialisation, protocol-version selection, capability exchange and the initialized notification. It must not advertise optional behaviour that it cannot honour, and it must not assume client capabilities such as sampling or elicitation.

Tool and resource lists can change only according to negotiated behaviour. Descriptions and schemas are behavioural contracts because they influence model selection. Changes require compatibility tests, staged rollout and a deprecation path.

Tool contracts and domain semantics

A tool should express a bounded user outcome rather than mirror every REST endpoint. Its contract defines purpose, input and output schemas, authorisation, side effects, idempotency, timeout, result limit and stable error classes. An annotation is a hint, not a security boundary.

For travel, the output preserves supplier provenance, retrieval time, currency, conditions and validity. Search, reprice, hold, order creation, payment and cancellation are separate risk classes and should not be collapsed into one universal booking tool.

Authorisation and downstream systems

A valid token is only the first control. The server validates issuer, signature, expiry, audience and scope and then applies tenant, role, object relationship and current business state. Consent in the host complements but never replaces server-side authorisation.

The MCP adapter should not pass arbitrary downstream tokens through. It uses defined delegation or minimal service credentials, while the GDS, CRS, PMS, order platform or payment provider continues to enforce its own domain rules.

Errors, idempotency and reconciliation

Errors distinguish malformed input, denied access, missing objects, domain conflicts, temporary dependency failure and internal defects. An expired offer is a domain conflict that can lead to repricing, not an unknown server crash.

Writes require idempotency because a network timeout can occur after the supplier changed state. Before retrying, the server reconciles the authoritative order, reservation or payment status. Partial confirmations and compensation remain explicit domain states.

Operations and production evidence

Production evidence includes protocol conformance, negative authorisation cases, model-selection regression tests, dependency failures, concurrency, result limits and recovery. A shared correlation identifier links host choice, server decision and supplier outcome without logging unnecessary personal data.

A maintained server has owners, service objectives, per-capability telemetry, runbooks, rollback, deprecation and kill switches. Registry publication or an Inspector demonstration does not establish security, commercial entitlement or operational maturity.

Worked contract for an offer-revalidation server

A revalidate_offer capability accepts an opaque offer identifier, expected version and market context. It returns supplier provenance, retrieval time, new version, total amount, currency, validity boundary and a structured list of material changes. It has no order-creation side effect. The description tells the model when the tool is appropriate and explicitly states that a changed result requires a new approval.

Before calling the supplier, the server validates token issuer, signature, expiry and audience, then checks tenant, role and object relationship. It bounds deadlines and result size, maps supplier outcomes into stable domain errors and records a correlation identifier. It never trusts the model to supply an unrestricted account, arbitrary endpoint or downstream credential.

Concurrency, cancellation and ambiguous outcomes

Travel shopping may fan out across suppliers, while booking and payment can outlive an interactive request. The server therefore defines concurrency limits, cancellation behaviour, a deadline budget and partial-result semantics. Cancellation of the client request does not prove that a downstream write was cancelled. Long-running work needs an explicit task or job state that the host can poll without claiming premature success.

An ambiguous timeout after a write is resolved by reconciliation, not blind retry. The server queries the authoritative order, reservation or payment system using the idempotency reference and returns the observed state. If one component of a package succeeded and another failed, each component remains explicit together with financial impact, compensation and manual escalation. MCP does not create a distributed transaction across independent suppliers.

Change management for model-facing contracts

Tool names, descriptions and schemas affect model selection and are therefore behavioural interfaces. A syntactically compatible wording change can alter which tool a model chooses. Releases need golden task sets, negative-selection cases, supported-client matrices and staged exposure. New fields should be introduced with clear semantics; renamed capabilities require a deprecation window rather than an unannounced replacement.

Operations should measure selection accuracy, rejected authorization, domain conflicts, supplier failures, result truncation, latency and recovery. Logs use structured references and redaction instead of complete prompts or traveller documents. Every consequential capability has an owner, service objective, runbook and independent kill switch.

Evidence that a server is ready for travel production

Readiness combines protocol conformance with domain and operational evidence. Tests cover initialization, version negotiation, malformed messages, unsupported capabilities, access to another traveller's object, expired offers, concurrent updates, duplicate writes, downstream timeout and partial confirmation. Security review includes prompt injection in tool results, SSRF and egress controls, token confusion, session isolation and secrets handling.

The final acceptance record names what remains outside scope. A registry listing, generated wrapper or successful Inspector call proves discoverability and basic interaction only. It does not prove commercial entitlement to a supplier, correctness of fare or cancellation semantics, privacy compliance, resilience or supportability.

Primary sources and specifications

• MCP specification 2025-11-25
• MCP architecture
• MCP security best practices
• IATA NDC
• IATA ONE Order
• OpenTravel specifications