Start with the job: understand MCP components and their security boundaries

MCP architecture is easiest to reason about when four concerns stay separate: the host application, its client connection, the server process or service, and the transport carrying messages. Collapsing those names hides who owns policy and lifecycle.

The protocol defines interaction contracts, but the host decides how users consent, which servers may connect and how tool calls reach approval. A server cannot grant itself authority merely by advertising a capability.

Keep this page's decision boundary canonical

Use the architecture model to localize failures and policy, not merely to name components. This page owns the host-client-server relationship and trust transitions. Separate pages own primitive selection and the stdio-versus-HTTP deployment choice, while security pages own authorization and injection controls. Keeping those decisions distinct prevents a transport fix from being mistaken for a permission fix and makes every connection's lifecycle and policy owner visible.

Trace one representative call across every layer. Begin with the user's action in the host, follow capability selection into the client, cross the transport, enter the server handler and reach the upstream dependency. At each transition, name the data shape, identity and component that can reject the call. This sequence makes it possible to distinguish protocol validation from application authorization and to see where untrusted results return to model context.

Then repeat the trace for discovery and shutdown, not only tool execution. Capability lists can change, subscriptions or notifications can alter state, and a stale host may continue presenting something a server no longer supports. The host needs rules for refreshing or removing that surface, while each client needs connection-specific error and lifecycle handling. Recording those non-happy paths prevents the architecture diagram from implying that initialization creates a permanent, static contract.

Make the operating boundary visible

The host may coordinate multiple clients, generally maintaining a distinct protocol relationship with each server. Initialization establishes version and capability agreement. Resources, tools and prompts then travel over stdio or Streamable HTTP according to their protocol methods.

FIG. 01 / Conceptual model

Host, client, server, transport

Architecture map separating MCP host policy, client session, server capability and transport
Conceptual model: protocol roles and the transport boundary remain separate from host authorization policy.

Build a reproducible path

For MCP Architecture: Host, Client, Server, and Transport, use a small fixture that another developer can repeat without privileged production data. Change one boundary at a time and preserve the exact configuration needed to explain how the page's decision was reached.

  1. Draw the host and every server as separate trust zones.
  2. Name the client connection and its negotiated capability set.
  3. Trace credentials and data across the selected transport.
  4. Assign policy, retry, shutdown and audit ownership to explicit components.

Keep secrets outside the mcp server architecture artifact. Record variable names, scopes and owners, then verify the relevant system of record whenever this tool or workflow can change external state.

Record evidence that survives a rerun

An architecture record should show more than boxes and arrows. Attach the negotiated version, server identity, transport endpoint or command, credential location and the component that can deny a consequential action.

  • Host policy and consent surface
  • Client session and lifecycle state
  • Server capability and upstream dependencies
  • Transport boundary, authentication and network path

Date the MCP Architecture: Host, Client, Server, and Transport record and keep factual observations separate from inference. If a claim depends on a hosted service, preview feature or moving SDK, name that dependency beside the claim.

Use a decision rule and a stopping rule

Choose the simplest topology that preserves these responsibilities. Local stdio can reduce network exposure but gives a child process local access; remote HTTP centralizes operation but introduces network identity, authorization and service lifecycle concerns.

Induce failures at one layer at a time: unavailable transport, incompatible initialization, invalid schema and denied upstream action. The observed error should identify the responsible layer instead of collapsing every failure into a generic tool error.

FIG. 02 / Decision aid

Place each responsibility once

Decision matrix assigning consent, lifecycle, schemas and upstream authorization to MCP components
Decision aid: every lifecycle and security responsibility needs one visible owner.

Protect against predictable failure and continue deliberately

For MCP Architecture: Host, Client, Server, and Transport, the architecture review flags three recurring failure modes: specification versions are mixed; local and remote trust boundaries are conflated; a server is recommended without permission review. Treat them as release checks, not footnotes. This page remains draft when its exact implementation or intent evidence is still research-gated.

Use the MCP field guide next: it reconnects the decision to protocol roles and versioned boundaries.

Use the MCP primitives guide next: it distinguishes resources, tools and prompts by interaction job.

Use the stdio versus HTTP comparison next: it chooses transport from deployment and lifecycle boundaries.

Use the MCP security threat model next: it traces data and tool access to concrete consequences.