How-To Guides · Certification Study Guide · 2026-07-10

Linux Foundation · AI & ML Track · Beginner

MCPA Exam Prep

Model Context Protocol Associate — a visual-first study guide

Everything on the official blueprint, sized to the exam weights, verified against the live MCP specification — stable 2025-11-25 as the exam baseline, with the incoming 2026-07-28 revision flagged throughout.

Where the exam weight lives — study time should mirror this

Interactions & Execution Security & Governance Use Cases & Ecosystem MCP Fundamentals Architecture & Components

3 · Interactions & Execution

26%

4 · Security & Governance

24%

5 · Use Cases & Ecosystem

20%

1 · MCP Fundamentals

16%

2 · Architecture & Components

14%

Contents

! · Spec Watch — the 2026-07-28 revision

A major new revision was about to land when this guide was written. Here's exactly where things stood as of 11 Jul 2026, and what to do about it. Update: 2026-07-28 shipped as a final release on 28 July 2026. The MCP Goes Stateless guide covers the final delta.

Exam-relevant deltas: 2025-11-25 → 2026-07-28 RC

Unchanged and safe to over-learn: the host/client/server model, the three server primitives and their control model, tool-invocation flow, OAuth 2.1 fundamentals (PKCE, resource indicators, audience validation, no token passthrough), and the whole security threat model. The RC re-plumbs transport & lifecycle, not MCP's core value or its trust model.

0 · Prerequisite Primer

No prerequisites are required, but the blueprint recommends this foundation. Every item below shows up indirectly on the exam. Skim if you know it; drill the JSON-RPC and OAuth pieces if you don't.

JSON-RPC 2.0 — the wire format MCP speaks

MCP is JSON-RPC 2.0 over a transport. Every message is one of three shapes. All must be UTF-8.

// Request
{ "jsonrpc": "2.0", "id": 1, "method": "tools/call",
  "params": { "name": "get_weather", "arguments": { "location": "NYC" } } }

// Success response          // Error response
{ "jsonrpc":"2.0","id":1,     { "jsonrpc":"2.0","id":1,
  "result": { ... } }           "error": { "code":-32602, "message":"..." } }

// Notification (no id → no reply)
{ "jsonrpc": "2.0", "method": "notifications/initialized" }

LLM API interaction & agentic patterns

Security basics you must recognize

Reading a server manifest / capability definition

An MCP server advertises what it can do during the initialize handshake and via */list calls. Being able to read a tool definition — name, description, inputSchema (JSON Schema), optional outputSchema and annotations — is an explicit exam skill.

Purpose & scope · core concepts · interoperability & value

What MCP is (and isn't)

The Model Context Protocol is an open standard that gives AI applications a uniform way to connect models to external tools, data, and context. Anthropic introduced it in November 2024; it is now community-governed. The canonical framing:

Core value: interoperability & portability

Schemas & structured data · hosts / clients / servers · model interaction flow

The three roles

Host / Client / Server — the participant model

HOST the AI application

The user-facing app that contains the LLM (e.g. Claude Desktop, an IDE, an agent). Owns the model, the UI, user consent, and the security policy. Spawns one client per server connection.

Client A ↔ Server 1

Client B ↔ Server 2

Client C ↔ Server 3

▲ one dedicated client per server · 1:1 · isolated ▲

SERVER 1 capability provider

Exposes tools, resources, and prompts. Runs locally (stdio) or remotely (Streamable HTTP). Holds its own credentials to the systems behind it.

EXTERNAL SYSTEMS outside the trust boundary

Databases, SaaS APIs, filesystems, the web. The server brokers access to these — the client/model never touches them directly.

Schemas & structured data

interaction patterns & response handling · error handling · tool invocation lifecycle · protocol primitives

3.1 The connection lifecycle — three phases

Initialize handshake & capability negotiation

1. Client → Server  initialize request — sends its protocolVersion, capabilities (roots, sampling, elicitation), and clientInfo.
2. Server → Client  initialize result — echoes an agreed protocolVersion, its own capabilities (tools, resources, prompts, logging, completions), serverInfo, optional instructions.
3. Client → Server  notifications/initialized — a notification (no id). Only now may normal operations begin.

2026-07-28 RC The handshake is removed — MCP becomes stateless. There is no initialize/initialized exchange; every request instead carries its protocol version, clientInfo, and capabilities in _meta (keys like io.modelcontextprotocol/protocolVersion). Servers must implement server/discover to advertise versions & capabilities; a version mismatch returns UnsupportedProtocolVersionError. Baseline answer for the exam today: the handshake still exists.

3.2 Tool invocation lifecycle

Discovery → selection → invocation → result

1. Discovery Client sends tools/list; server returns tool definitions (name, description, inputSchema). Supports pagination via cursor.
2. Selection The model chooses a tool based on the user's intent (tools are model-controlled). A human-in-the-loop should be able to approve/deny.
3. Invocation Client sends tools/call with name + arguments (validated against the schema).
4. Result Server returns a result: content[] (text/image/audio/resource_link/embedded resource) and/or structuredContent, plus isError.
5. Feed back Client passes the result to the model to continue reasoning. Loop may repeat (ReAct).
6. Live updates If the server declared listChanged, it can emit notifications/tools/list_changed; the client re-lists.

3.3 Protocol primitives — the core of the exam

Three server primitives, distinguished by who controls them. This "who controls what" mental model is the single most-tested idea in this domain.

MCP also defines client primitives — capabilities a server can call back into the client (declared by the client at initialize):

2026-07-28 RC Roots and Sampling are deprecated (along with Logging). And server-initiated callbacks disappear: instead of the server calling the client (sampling/createMessage, elicitation/create, roots/list), the server returns an InputRequiredResult and the client retries the original request with inputResponses — the Multi Round-Trip Request (MRTR) pattern, which keeps everything stateless. Baseline exam answer: these are still live server→client requests.

3.4 Error handling — two distinct mechanisms

// Protocol error — unknown tool
{ "jsonrpc":"2.0","id":3, "error":{ "code":-32602, "message":"Unknown tool: foo" } }

// Tool execution error — tool ran, but failed (model sees this)
{ "jsonrpc":"2.0","id":4, "result":{
    "content":[{ "type":"text","text":"API rate limit exceeded" }],
    "isError": true } }

2026-07-28 RC The protocol-error vs isError split is unchanged, but two details move: resource-not-found changes from -32002 to -32602 (Invalid Params), and MCP now reserves the -32020…-32099 band for spec-defined codes. The isError:true convention for tool-execution failures stays exactly the same.

trust boundaries · permissions & consent · risk & safety controls · auditability & observability

4.1 Trust boundaries

Where trust changes hands — each boundary is a control point

① User ↔ Host

The host must obtain informed consent and present clear UI: which tools are exposed, visual indicators when a tool runs, confirmation prompts for sensitive actions.

— consent boundary —

② Host/Client ↔ Server

Each server is isolated behind its own client. The client must treat server-supplied content (descriptions, tool annotations) as untrusted unless the server is trusted. Capabilities gate what's even possible.

— protocol / auth boundary (OAuth 2.1) —

③ Server ↔ External API

The server uses its own credentials/token for downstream systems. It must not pass the client's token through to the API (see confused deputy / token passthrough).

4.2 Permissions & consent — the guiding principles

The spec's trust-&-safety principles: user consent and control, data privacy, tool safety (treat descriptions as untrusted; confirm before running), and LLM sampling controls (user approves what the model is asked to generate).

4.3 Authorization — OAuth 2.1 (HTTP transports)

Authorization is optional and applies to HTTP-based transports. stdio servers use environment credentials instead. When present, the MCP server is an OAuth 2.1 Resource Server; a separate Authorization Server issues tokens.

Discovery & token flow (abridged)

1. Client → Server Request with no token → 401 Unauthorized + WWW-Authenticate header pointing at resource metadata.
2. Discovery Client reads Protected Resource Metadata (RFC 9728) → finds the Authorization Server → reads AS Metadata (RFC 8414; OIDC Discovery added 2025-11-25).
3. Registration Dynamic Client Registration (RFC 7591) or, new in 2025-11-25, Client ID Metadata Documents.
4. Authorize Browser flow with PKCE (mandatory) + resource indicator (RFC 8707) naming the target server.
5. Token AS issues a short-lived access token bound to that server's audience.
6. Use Authorization: Bearer <token> on every request — never in the query string. Server validates the audience before acting.

2026-07-28 RC Still OAuth 2.1 — the fundamentals below don't change — but hardened: clients must validate the iss parameter (RFC 9207) before redeeming a code, credentials are bound to their issuing authorization server, and clients declare an application_type at registration. Note Dynamic Client Registration is now deprecated in favor of Client ID Metadata Documents.

4.4 Risk & safety controls — threats you must recognize

4.5 Auditability & observability

2026-07-28 RC The logging capability is deprecated — servers log to stderr (stdio) or emit OpenTelemetry instead, with W3C trace context (traceparent/tracestate/baggage) carried in _meta. The consent, audit-logging, and human-in-the-loop principles are unchanged; only the built-in logging mechanism moves.

roles / responsibilities / adoption · operational use cases · ecosystem & portability

Who does what (adoption roles)

Operational use cases

Ecosystem & portability

Q · Quick-Reference Tables

Remember: a tool that runs but fails is not a code above — it's a normal result with isError:true.

2026-07-28 RC Resource-not-found moves from -32002 to -32602; the MCP spec reserves -32020…-32099 for its own codes (-32000…-32019 stays implementation-defined). The generic JSON-RPC codes above are unchanged.

Streamable HTTP security must-knows: validate Origin (return 403 if bad, per 2025-11-25), bind to localhost when local, use HTTPS — to stop DNS-rebinding.

2026-07-28 RC Streamable HTTP goes stateless: the Mcp-Session-Id header and SSE resumability (Last-Event-ID) are removed; POSTs must carry Mcp-Method + Mcp-Name routing headers; list/read results gain ttlMs + cacheScope cache hints; and change notices use one subscriptions/listen stream. HTTP+SSE is now formally reclassified Deprecated under the lifecycle policy.

P · Practice Questions

22 items, deliberately over-weighted to Domains 3 (26%) and 4 (24%), with two on the incoming 2026-07-28 revision. Tap Show answer to reveal the explanation. Try to answer before revealing.

S · Study Plan & Checklist

A focused 7-day pass, front-loading the two heavy domains. Adjust to your pace; the ordering (weight-first) is the point.

Mastery checklist

• I can state the M×N → M+N value prop in one sentence.
• I can label host vs client vs server and their 1:1 relationship.
• I can order the initialize handshake and name what's negotiated.
• I can say who controls tools vs resources vs prompts — and name the client primitives.
• I can distinguish a protocol error from an isError:true tool execution error, with examples.
• I can recite the common JSON-RPC error codes (-32700/-32600/-32601/-32602/-32603/-32002).
• I can name the three transports, which is current/deprecated, and their auth model.
• I can walk the OAuth 2.1 discovery→token flow and name PKCE + resource indicators + audience validation.
• I can match each named attack (token passthrough, confused deputy, session hijack, SSRF, prompt injection) to its mitigation.
• I can explain the human-in-the-loop / consent principles and why they exist.
• I know the current stable spec is 2025-11-25 (the exam baseline) and what it changed vs 2025-06-18.
• I know the 2026-07-28 RC is imminent and can name its headline changes: stateless (no handshake, no Mcp-Session-Id), MRTR, Tasks/MCP-Apps as extensions, Roots/Sampling/Logging deprecated, -32002→-32602.

X · Exam-Day Logistics

R · References & Sources

All links verified against live pages on 2026-07-10. The specification is the authoritative source; study it directly.

MCPA Exam Prep Study Guide · built 2026-07-10, spec-checked 2026-07-11 · baseline MCP spec 2025-11-25, with the 2026-07-28 release candidate flagged throughout. Confirm exam price, question count, passing score & which spec revision the exam currently targets on the official LF page before booking.