FACT COPY · EN
Fact copy: Architecture of an MCP system
Layers, responsibilities, data flows and security boundaries in MCP architectures.
Canonical source: https://travel-mcp.com/en/mcp-architecture/
Factual summary
Layers, responsibilities, data flows and security boundaries in MCP architectures.
Precise scope and non-goals
Architecture of an MCP system must be understood as the separation of host orchestration, client sessions, domain servers, authorization services, gateways and systems of record. 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 independent flight, hotel, profile, payment and document domains joined by correlation rather than one privileged universal server. 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 shared credentials, lost tenant context, cross-server data leakage, confused-deputy flows and a gateway becoming an unrestricted super-server. 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 data-flow diagrams, trust boundaries, object-authorization tests, failure isolation and end-to-end trace correlation. 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.
Deployment topology and trust-boundary checklist
A production diagram should show the user, host, one client per server connection, authorization server, gateway where used, domain servers, downstream systems and telemetry boundary. For each arrow it records identity, token audience, protocol and data classification. This prevents a logical MCP diagram from concealing the actual credential and data paths.
Local stdio and remote Streamable HTTP deployments create different risks. Remote multi-user services require transport security, Origin validation, protected-resource metadata, tenant isolation and explicit session handling. Domain servers should align with coherent ownership and authorization boundaries rather than mirroring every backend. Product, order, profile and payment frequently justify separate controls even when they share infrastructure.