FACT COPY · EN
Fact copy: MCP clients
The role of MCP clients in agentic applications.
Canonical source: https://travel-mcp.com/en/mcp-clients/
Factual summary
The role of MCP clients in agentic applications.
Precise scope and non-goals
MCP clients must be understood as the stateful connection and policy boundary managed by an AI host for one MCP server. 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 selecting only the capabilities relevant to shopping, servicing or disruption while keeping server origin, traveller context and approval visible. 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 loading every tool into model context, treating discovery as trust, reusing approval after a price change and mixing identities across sessions. 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 client compatibility matrices, tool-selection precision, approval binding, session isolation and revocation 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.