MCP architecture: hosts, clients and servers

MCP architecture separates an AI host, its protocol clients and the servers that provide external capabilities. The host owns model interaction and orchestration; a client makes protocol requests; a server supplies tools, resources or prompts. A gateway can add shared routing and access policy between clients and upstream capabilities.

The conceptual roles are stable, but the wire sequence depends on the revision. Official documentation checked on October 14, 2026 identifies 2026-07-28 as the current specification. Older initialization-based examples need an explicit version label rather than being presented as the current universal flow.

MCP hosts, clients and servers

The host is the application where the user works. It may be a desktop assistant, editor or command-line agent. It chooses what context to send to the model and decides whether a proposed operation should execute. It can also manage several external capability providers at once.

A client is the protocol component inside that host. Its job is to communicate with a server and make capabilities available to the surrounding application. A host commonly creates one client per server, which keeps the connections and capability boundaries separate.

The server provides a defined interface to underlying operations or content. It need not call a model. A calculator, a document reader and an API adapter all fit the role. See what is an MCP server for examples and MCP clients for the requesting side.

Component	Owns	Should not be assumed
Host	User interaction, model loop and execution decisions	That every proposal is already authorized
Client	Protocol requests and server interaction	That it supplies a separate language model
Server	Capability contract and permitted execution	That all advertised operations are safe
Upstream application	Business objects and account permissions	That a gateway can override its restrictions
Gateway	Routing and an additional policy boundary	That all client approval behavior is enforced there

The official architecture reference describes these roles. Keep them visible in a design review: a failure to distinguish the model proposal from the executor is often a failure to identify where validation should happen.

MCP server architecture diagram

A host can talk to multiple servers. Each may have its own credentials, transport and upstream services. The following topology is conceptual and intentionally omits revision-specific request names.

Two connections do not imply two unrelated security decisions. A tool result from one server can influence a model proposal aimed at another. An issue description containing hostile instructions might persuade the assistant to send data through an email tool. Review the combined host surface, not only each server in isolation.

Separate accounts deserve the same care. If two servers or connections target different workspaces, the operation should identify the destination clearly. Centralizing names without preserving account identity can make a tool list look simple while making the action boundary harder to understand.

How an MCP tool call travels to your app

The user requests a task. The host supplies relevant context and tool definitions to the model. The model may propose an operation and arguments. The host validates that proposal and applies its execution policy before the client sends a request.

The server then validates the caller and input according to its deployment and executes the authorized upstream action. The upstream API applies its own permissions and business rules. The server returns a result, and the host decides how to present or use it.

This sequence shows responsibility, not the 2026-07-28 message envelope. Approval, where present, belongs to a specific implementation. Do not infer it from the tool proposal itself or from the presence of an authentication token.

Errors can occur at each boundary. A schema error means the arguments were invalid. A policy denial means execution was not allowed. An upstream timeout may leave the business outcome uncertain. These cases should not all be flattened into a generic result that encourages the model to retry a write blindly.

MCP data layer and transport layer

The data layer defines protocol messages, request methods and capability structures. Transport carries those messages. Keeping the layers separate makes it possible to expose similar tools locally and remotely without pretending the runtime environments are equivalent.

A tool schema describes the shape of accepted arguments. It does not validate the business meaning of every value or authorize the caller. A string that is syntactically a URL may still target an internal resource the caller should not reach. Validation should cover both shape and permitted behavior.

Capability support also matters. Tools, resources and prompts are different families, and optional features are not guaranteed by general protocol support. Read the primitives guide before designing a server that expects every host to show the same UI.

Use an SDK for framing and version behavior when possible. Hand-written request examples can teach the concept but easily become stale. Pin the SDK version, record the protocol support you tested and verify that your chosen host can use that combination.

Local stdio vs remote Streamable HTTP

With stdio, the host generally launches a subprocess and exchanges messages through standard streams. The server code runs under the process permissions you provide. Installation and environment credentials therefore belong in the threat model.

With Streamable HTTP, requests cross a network boundary. The deployment must handle authorization, endpoint exposure and service availability. Sharing a remote endpoint can simplify installation, but it introduces an operator and network path that need review. See remote servers for that deployment choice.

Transport	Useful property	Practical risk to examine
stdio	Close to local tools and files	Executable/package access to the host environment
Streamable HTTP	Reachable shared service	Authorization, operator trust and request exposure
Older HTTP+SSE	Existing legacy deployments	Current client compatibility and migration requirements

The old HTTP+SSE transport should not be treated as another name for the current HTTP transport. Configuration examples and URL expectations can differ. A connection succeeding in one older client does not prove compatibility in another host or protocol revision.

MCP version negotiation and discovery

The current revision uses per-request metadata and requires servers to implement server/discover. Clients may probe discovery before other requests. Earlier 2025-11-25 implementations used initialize and notifications/initialized; that older sequence should be labeled when explained. Source: current change summary.

A published revision is not evidence that every product implements it. An SDK can support compatibility paths, and deployed hosts may update on different schedules. For AIPx specifically, this article does not claim implementation of the current revision without product evidence.

Record compatibility as a set of facts: host version, server/SDK version, transport, authorization method and required capabilities. That is more useful than a single “MCP supported” checkbox. When a connection fails, inspect these facts before changing credentials or broadening access.

Cross-call state also deserves attention. Business operations may need a job identifier or record handle even when protocol interaction is stateless. Passing an explicit handle does not make the business workflow stateless, and the server still needs to authorize access to that handle.

Where a gateway fits in MCP architecture

A MCP gateway can consolidate upstream access behind a client-facing endpoint. It routes requests and applies its own access boundary. The server or application beneath it continues to own its own credentials, validation and account permissions.

AIPx connects supported accounts and gives configured agents separate endpoints. Rules attach to tool × account × agent. Allow and Confirm are execution hints, so a client must honor approval metadata for Confirm to produce a review step. Hide is enforced server-side and removes the tool from the agent surface. See permissions for the distinction.

This additional layer can be useful when several agents need different access to the same account. It also adds a trust and failure boundary. A direct official endpoint may be simpler for one narrow task, while an operator-owned gateway may fit internal infrastructure better.

Audit records help identify the requested account and operation, but they do not automatically explain the full model conversation or all causal decisions. Inspect the observability guide alongside the security guide. Architecture should make those evidence boundaries explicit so operators know which system to consult when something goes wrong.

Further reading

what is mcp.