Model Context Protocol (MCP) is useful when an AI application needs a consistent way to discover and use external context or capabilities. It is not a permission system and it does not make an external system trustworthy by itself. Its architecture separates the AI application that coordinates connections from the client and server components that communicate across each connection.

MCP architecture map:

  • Host: coordinates clients and owns connection permissions, consent, user-authorization decisions, and security boundaries.
  • Client: is created by the host and maintains one stateful connection to one server.
  • Server: operates independently with focused responsibilities and exposes its declared tools, resources, and prompts subject to security constraints.
  • Primitives: tools are model-controlled, resources are application-controlled, and prompts are user-controlled.
  • Capabilities and trust: initialization negotiates the protocol features and primitives available for that session; the host manages integration trust, while the destination system enforces access to its own data and effects.

Architecture Overview: Roles and Connections

An MCP host is the AI application that coordinates one or more MCP client instances. Each client maintains a one-to-one connection with an MCP server; a server exposes focused capabilities to its connected client. The protocol's architecture emphasizes these boundaries so that a host can manage integration and security policy without turning every server into an unrestricted part of the application.

This division suggests a practical design rule: the host owns the user experience, connection decisions, and policy integration; the client owns protocol communication for one server; the server owns only the capabilities it explicitly exposes. Do not collapse these responsibilities simply because a prototype has one process.

Lifecycle and Capability Negotiation

An MCP connection begins with initialization, during which client and server negotiate protocol version and supported capabilities. Initialization is followed by normal operation and, eventually, shutdown. Design against the capabilities actually negotiated on a connection rather than assuming every server supports every primitive or optional feature.

Version labels matter here. This article uses the public MCP specification revision dated 2025-06-18. A production integration should validate the server and client versions it deploys and fail safely when an expected capability is absent or incompatible.

Server Primitives: Tools, Resources, and Prompts

MCP servers can expose three main primitives with different control models:

  • Tools are model-controlled: the model can discover and invoke them, subject to host policy and user consent.
  • Resources are application-controlled context that a client can list, read, or subscribe to as supported.
  • Prompts are user-controlled templates that the user explicitly selects or invokes.

The specification distinguishes these primitives because “available to the model” is not the same as “automatically read” or “user-selected.” Use the primitive that matches who should initiate use and how much context or side effect is appropriate.

For example, a read-only project reference may fit a resource, a repeatable user-invoked workflow may fit a prompt, and a carefully authorized operation may fit a tool. That is an architectural classification, not a substitute for the detailed input and result design of an individual tool.

An MCP connection crosses a boundary whenever it gives an AI application access to a system with its own data, credentials, or effects. The specification's security guidance places users in control: hosts should obtain user consent before exposing data or invoking tools, and authorization must be enforced by the relevant system rather than delegated to the model.

Apply that principle at several layers:

  • Trust a server only after verifying its distribution and operational ownership.
  • Scope credentials to the server and capability that need them; do not share a broad host credential by default.
  • Require the destination system to authorize the actual user or service identity for every sensitive operation.
  • Present meaningful consent for data disclosure and side effects, especially where a tool can modify records, run commands, or incur cost.

Descriptions and capability advertisements help a model choose an action, but neither creates authorization. A server must validate inputs and enforce its own rules even when the host has already applied a policy.

Isolation and Operational Design

Run each server with the smallest practical filesystem, network, identity, and secret access. Keep connection setup, allowed servers, and user-facing trust decisions centrally observable at the host. Where an integration processes regulated or customer data, log the authorization and consent decision without logging the sensitive content itself.

Treat notifications, resource updates, and tool calls as events that can fail, arrive late, or exceed an application budget. Bound time, payload size, and retry behavior. An unavailable server should degrade only the capability it owns; it should not silently turn into an unrestricted fallback to another system.

Common Architecture Mistakes

The first mistake is equating “MCP server” with “safe connector.” A protocol connection does not prove that a server is benign or that a user has approved every future action. The second is using a tool for passive reference data or a prompt for an automated action, which confuses user control and model control.

The third is duplicating tool-call schema logic in the host and server without deciding which layer is authoritative. Define the integration boundary first, then design individual tool input, result, error, retry, and idempotency contracts at that boundary.

Conclusion

MCP provides a vocabulary for connecting AI applications to external capability without erasing ownership. The host coordinates, each client connects, and each server exposes limited primitives. Architect the negotiated capabilities, consent, authorization, isolation, and failure behavior as deliberately as the protocol messages themselves.

Authoritative Sources