MCP Architecture Guide: Hosts, Clients, Servers, Tools, Resources and Prompts

By Chris M. · Enterprise Technology & AI Systems · Reviewed August 9, 2026 · 6 min read

MANUAL REVIEW · AUG 9, 2026CONFIDENCE · HIGHPRIMARY SOURCESORIGINAL FRAMEWORKEDITORIAL METHOD →

A current, implementation-oriented explanation of Model Context Protocol using the 2026-07-28 specification, with architecture boundaries, transports, primitives, and production design guidance.

IN 45 SECONDS

MCP is best understood as an integration boundary, not an “agent framework.” A host manages the user-facing AI application, clients maintain protocol relationships, and servers expose focused capabilities such as tools, resources, and prompts. Security depends on keeping those responsibilities explicit.

Three decisions that matter

The current MCP specification is 2026-07-28; older 2025 baselines should not be presented as current.
Tools perform actions, resources provide context, and prompts provide reusable interaction templates.
MCP reduces custom integration work, but it does not remove the need for identity, authorization, evaluation, or recovery.

The architecture mental model

Model Context Protocol standardizes how AI applications connect to external capabilities. The protocol does not decide which model to use, how an agent plans, or whether an action is safe. Those are host-application responsibilities.

ORIGINAL XTIANZ FRAMEWORKMCP responsibility boundary

01UserIntent and approval

02HostPolicy, model, orchestration

03MCP clientProtocol connection

04MCP serverFocused capability

05Enterprise systemData or action

XTIANZ original framework

A useful design rule is one focused responsibility per server. An MCP server that exposes read-only documentation behaves differently from one that can change cloud infrastructure. Keeping capabilities narrow makes identity, authorization, testing, and incident response easier.

Tools, resources and prompts are different primitives

Primitive	Purpose	Examples	Primary concern
Resource	Context the application can read	File, schema, record, document	Grounding and discovery
Tool	A callable capability	Query, create, update, calculate	Retrieval or action
Prompt	Reusable structured instruction	Workflow template	Consistent user/model interaction

The distinction is operationally important. A resource is not automatically safe just because it is read-only; sensitive context still needs access control. A tool deserves stronger scrutiny because it can cause side effects. A prompt can encode a workflow but should not be treated as a policy boundary.

Transport is separate from protocol meaning

The 2026-07-28 specification separates protocol semantics from transport bindings. Local process integrations can use STDIO. Remote services can use HTTP-based transports. That choice changes deployment and credential handling but should not change the meaning of the MCP messages themselves.

For enterprise design, transport choice affects network policy, TLS, service identity, proxying, observability, and fault isolation. A local server may inherit the user’s environment and workstation trust boundary; a remote server becomes a network service that needs normal service controls.

What changed in the 2026-07-28 specification

The July 2026 specification is the current release. It introduces a more stateless core, an extensions framework, changes around long-running work and app experiences, authorization hardening, and a formal deprecation path. Teams maintaining older 2025 implementations should review the changelog rather than assuming behavior is unchanged.

Migration principle

Do not upgrade only the SDK. Review authentication, capability assumptions, request lifecycle, error handling, and any custom extensions as part of the protocol-version change.

A production MCP checklist

Capability inventoryKnow every server and tool the host can reach.

Identity boundaryMap user, host, client, server, and upstream identities.

AuthorizationScope access to the intended resource and action.

Schema validationReject unsafe or malformed tool arguments.

ObservabilityRecord server, tool, request, result and policy decision.

RecoveryDesign revocation and rollback before write access.

PRIMARY SOURCES

Sources used for this review

XTIANZ links to specifications, product documentation, filings, regulators, and government sources so readers can verify fast-changing claims directly.

MCP 2026-07-28 specificationCurrent authoritative specification
MCP architectureHost, client, server and primitive responsibilities
MCP changelogChanges since 2025-11-25
MCP authorizationOAuth-based authorization for HTTP transports

ABOUT THE AUTHOR

Chris M.

Enterprise technology and AI systems practitioner with more than two decades of experience across global operations, infrastructure, collaboration platforms, cloud services, reliability, and technical leadership.

Experience and review approach →

Review history

August 9, 2026 — Reworked as a flagship XTIANZ guide with current primary sources, original decision frameworks, and technical review.

Suggest a correction ↗

Disclosure

AI tools may assist research organization, drafting, code, and quality checks. The final structure, claims, frameworks, and publication decision are manually reviewed. XTIANZ does not accept payment to change technical conclusions.