ALLMAcademy

C1

MCP: Host, Client, Server, and Primitives

16 min2 optional deep dives

Understand the MCP connection model, who controls each primitive, and where consent and trust belong.

  1. 01Explain host, client, and server responsibilities
  2. 02Distinguish model-controlled tools, application-controlled resources, and user-controlled prompts
  3. 03Apply consent and trust checks at the host boundary
  4. 04Explain how current Streamable HTTP differs from the deprecated HTTP+SSE transport

Three MCP roles

architecture
  • Host — the AI application that owns the user experience, consent, and context.
  • Client — one connector inside the host for one server connection.
  • Server — a separate program that exposes capabilities and context.
MCP host, clients, and serversInteractive · 2D

The model sits inside a host application. The host creates one MCP client per external server and routes requests through that boundary.

Loading diagram…
Text description

The model sits inside a host application. The host creates one MCP client per external server and routes requests through that boundary.

Tools, resources, and prompts

Primitive Who chooses it? Example
Tool Model Create an issue
Resource Application Attach a file or database record
Prompt User Run a named review template

The host may add stronger controls. A payment tool can require confirmation even when the model selects it.

Production failure modes

  • A malicious server description tries to persuade the model to reveal unrelated data.
  • A tool result contains prompt injection that is passed back without validation.
  • A remote server receives more context than the user approved.
  • A client treats the transport connection as a hidden session and relies on earlier requests.
Deep dive: Local, legacy remote, and current remote transports

Local servers commonly use stdio: the host launches a subprocess and exchanges messages over standard input and output. Remote servers commonly use Streamable HTTP and need network authentication, TLS, tenancy checks, and revocation.

Transport Connection shape Status
stdio Newline-delimited messages over a host-launched subprocess Current for local servers
HTTP+SSE (2024-11-05) A dedicated GET SSE stream announces a separate POST endpoint Deprecated
Streamable HTTP (2025-03-26–2025-11-25) POST plus optional standalone GET SSE, session IDs, resumable streams, and initialize Earlier revision
Streamable HTTP (2026-07-28) POST-only messages with request-scoped responses; no protocol session Current revision

The 2026 revision removed the long-lived GET stream endpoint and protocol-level sessions. That does not mean “SSE disappeared”: a POST response may still use SSE when the server needs to stream multiple messages. It means the stream belongs to that request instead of acting like a hidden application session.

Compatibility is versioned, not one blind fallback. A current client tries a modern request first:

  1. a recognized modern JSON-RPC error means “negotiate an advertised version or correct the request,”
  2. an empty or unrecognized 400 can trigger the older initialize handshake used by earlier Streamable HTTP revisions,
  3. support for deprecated 2024 HTTP+SSE is a separate compatibility path: only after a POST returns 400, 404, or 405 with no recognized modern JSON-RPC error does a GET that returns an endpoint event identify that old transport.

New servers should not adopt HTTP+SSE, and clients should not mistake a modern validation error for permission to downgrade.

Clients can also expose capabilities back to servers. In the 2026-07-28 protocol, elicitation lets a server request additional user input through the host. Keep that flow visible to the user; it is not permission for a server to open an invisible side channel.

References & deeper reading (4)

Retrieval Practice

Check one idea at a time

Question 1 of 5

An IDE connects to a filesystem server and an issue-tracker server. How many MCP client connections does the host manage?