Model Context Protocol Associate
Prove you understand how the Model Context Protocol works: its hosts, clients, servers, and tools, the message flow and primitives that connect them, and the trust boundaries that keep the connection safe.
The official exam
- Questions
- About 60 (not officially published)
- Time
- 90 minutes
- Fee
- US$250
- Passing score
- Not published
- Valid for
- 24 months
- Format
- Multiple choice
- Delivery
- Online proctored
As published by the Agentic AI Foundation (September 2026); checked 24 September 2026. Read the official exam guide
Who it's for
AI engineers, platform engineers, and AI governance professionals who connect agents to external systems and need to reason about how the protocol works and how its components communicate.
- Foundational knowledge of JSON-RPC or a similar message-based protocol
- Experience calling LLM APIs such as OpenAI, Anthropic, or a local model
- Understanding of agentic patterns such as tool use and the think-act-observe loop
- Basic security literacy: API keys, OAuth 2.1, token handling, and authentication headers
- Ability to read an MCP server manifest and its capability definitions
What the exam covers
- MCP Fundamentals16%
- Architecture and Components14%
- Interactions and Execution26%
- Security and Governance24%
- Use Cases and Ecosystem20%
Practice exams
Original questions in the official format, timed like the real thing, with a breakdown by exam domain and an explanation for every answer. Start with the diagnostic.
- MCPA Foundations Diagnostic30 questions, 30 minutesFree
- MCPA Full-Length Mock 1: Operational Scenarios60 questions, 90 minutes
- MCPA Full-Length Mock 2: Wire-Level Messages60 questions, 90 minutes
- MCPA Full-Length Mock 3: Design and Security Trade-offs60 questions, 90 minutes
Lessons
- 1The MCPA Blueprint Is a Study Budget, Not a ChecklistA syllabus lists what might appear on an exam. A blueprint states how often each part actually does. Read the MCPA blueprint as a budget for your study hours, not a table of contents to skim once and forget.
- 2Reading the MCP SpecificationThe specification is normative text, not a tutorial: a MUST decides an implementation, a SHOULD leaves room for judgment, and a feature's Deprecated state tells you exactly how long you can still rely on it.
- 3The Integration Problem MCP SolvesEvery system you connect to an AI application is a contract. MCP makes that contract the same shape everywhere, so one client can use a server it has never seen before.
- 4The JSON-RPC EnvelopeA server that has never talked to you before still has to know, from this one message alone, whether you expect an answer, which protocol version you speak, and where your metadata ends and your arguments begin.
- 5The Stateless Core of MCPEvery request carries everything a server needs to answer it; nothing carries over from the request before it, not even on the same connection.
- 6Telling a Modern MCP Server From a Legacy OneModern MCP has no opening handshake, so a client that must work with both current and older servers has to work out which kind it is talking to from how the very first exchange behaves, not from anything either side announces up front.
- 7Hosts, Clients, and Servers: MCP's Process TopologyA host never talks to a server directly, only through one client per server. That single binding is where MCP draws its trust boundaries, and where a host aggregating many servers has to start resolving name collisions.
- 8Discovering a Server and Negotiating What It Can DoA server describes itself once through server/discover, but every request still declares its own capabilities: nothing the server needs is assumed just because a client asked what was available.
- 9The Contract Inside a Tool DefinitionAn inputSchema is not a suggestion the model can approximate: a server checks arguments against it before a handler ever runs, and a broken argument still comes back as a result the model can read and fix.
- 10Reading a Server Manifest Like a ReviewerA server's discover result, its tool list, and its registry entry are the only things you know about it before you call anything, so read them the way you read a contract, because an unread default becomes a promise you did not mean to…
- 11The Model Interaction FlowA tool call is not one message on the wire. It is a loop the host runs between a user, a model, and a server, and every turn of that loop decides what the model gets to see next.
- 12The Tools Primitive: Calling Actions and Reading Their ResultsA tool call is a request like any other. What earns it its own lesson is everything the result can carry back: plain text, an image, audio, a link to a resource, or a resource embedded whole, each one tagged with hints about who it is for…
- 13Resources: Addressable Content for a Stateless ServerA tool answers a question by doing something. A resource answers it by being something the host can already point the model at, addressed by a URI instead of invoked by a name.
- 14Prompt Templates and Argument CompletionA prompt is a template the server writes and the user chooses to run. Nothing about it should surprise the person who picked it.
- 15Multi Round-Trip Requests and ElicitationA server that needs the user's confirmation mid call does not hold a connection open and wait. It ends the call, hands the client a receipt, and lets a brand new request pick up where the first one left off.
- 16Deprecated, Not Removed: Roots, Sampling, and LoggingDeprecated in MCP 2026-07-28 does not mean gone: roots, sampling, and logging still answer exactly as before, and only a twelve month clock has started.
- 17The Subscription Stream: Notifications, Progress, and CancellationA notification never gets a reply, so it has to say on its own which conversation it belongs to: the long-lived stream that opened it, or the one request that is still waiting on it.
- 18The Tool Invocation LifecycleA tool call is not one event. It is a fixed sequence of checkpoints, and exactly where a call stops tells you which of two error channels applies and what a caller should do next.
- 19Two Ways for a Request to FailA failed request does not get to invent its own vocabulary. MCP 2026-07-28 fixes a small set of numbers, splits every failure into one of two channels, and puts a firm list of numbers permanently out of reach.
- 20Transports and the HTTP Header ContractA transport does not change what a message means, only how it travels: stdio hands a JSON-RPC line to a subprocess, and Streamable HTTP posts one message at a time while mirroring a few of its fields into headers a gateway can read without…
- 21Cache Freshness and Cursor-Based PaginationA cacheable result tells a client exactly how long to trust it and who else may reuse the copy; a paginated one hands back an opaque bookmark, never a page number.
- 22Long-Running Work and the Tasks ExtensionBlocking a connection until minutes or hours of work finish gives up everything statelessness bought: any replica can no longer answer, and a dropped connection loses the job. The tasks extension trades that blocking call for a durable…
- 23Trust Zones in an MCP ExchangeA tool result is data the server chose to send, not a message the host already trusted. Draw the zones before you draw the arrows.
- 24Authorizing Access to an MCP ServerA bearer token proves the client was issued credentials for this server, not that the server should trust everything the token's holder asks for, so the protocol makes the client prove the token, prove the audience, and prove the issuer…
- 25Proving a Client's Identity to an Authorization ServerAn MCP client and the authorization server guarding a new server have usually never met, so before anything is authorized, the authorization server first has to decide whether it believes the client is who it claims to be.
- 26Consent and Least PrivilegeA tool call that changes something in the world should not run just because a model decided to call it. It should run because a human said yes to that specific call, and the client should hold no more access than that call actually needs.
- 27Risk and Safety Controls for MCP Tool CallsA tool description is not documentation the model happens to see. It is a string the model reads as instructions, which makes it the cheapest place to attack a system that otherwise looks fully locked down.
- 28One Trace ID Ties Auditability to ObservabilityA trace id is the one value that follows a single call through a client, a server, and whatever that server calls next, and a hash chain is what lets you prove, months later, that the record of what happened has not been quietly edited.
- 29Every MUST Needs an OwnerThe specification hands its MUSTs to a host, a client, and a server. A live deployment hands them to people, and the MUST nobody agreed to own is the one that fails first.
- 30Choosing MCP's Shape for the JobFour questions, who initiates the call, how sensitive the data is, how long the work runs, and whether a human needs to see it, turn a vague request into a specific choice of primitive, transport, auth path, and extension.
- 31The Extensions FrameworkAn extension is a capability neither side has to support: named with a mandatory vendor prefix, declared fresh in the metadata of every request, and safe to ignore, so the core protocol never has to grow to fit one vendor's idea.
- 32Interactive Interfaces Inside the ConversationA tool result does not have to stop at text: a server can point at a small HTML interface and let the host render it, sandboxed, right where the conversation is already happening.
- 33Finding, Routing To, and Trusting a ServerA name in the registry is a claim about who published a server, not a guarantee about what it does. A gateway decides whether a request may reach that server at all. An SDK's tier says how much of the protocol its implementation actually…
- 34Reading One MCP Exchange End to EndA production incident does not announce which MCPA domain it belongs to. It hands you a transcript, and reading that transcript correctly, stage by stage, is the whole skill this certification tests.
Go deeper in the Academy
- Stateless Requests and Discovery (Phase 13): Build the per-request metadata model and server/discover from first principles
- Building a Server (Phase 13): Implement tools, resources, and prompts on the stateless core
- Building a Client (Phase 13): Drive servers you did not write through discovery and capability negotiation
- Transports (Phase 13): Frame stdio and Streamable HTTP correctly, including the required headers
- Resources and Prompts (Phase 13): Application-driven context and user-controlled templates in depth
- Model Completions Through the Client (Phase 13): The deprecated sampling feature, how it works under MRTR, and its migration
- Scope and User Input (Phase 13): Roots, elicitation, and multi round-trip requests in depth
- Durable Long-Running Work (Phase 13): Task handles, polling, and mid-flight input
- Interactive Interfaces (Phase 13): Sandboxed UI resources rendered by the host
- Tool Poisoning Defenses (Phase 13): Untrusted descriptions, results, and definition drift
- Authorization (Phase 13): OAuth 2.1, protected resource metadata, and audience binding
- Production Tokens (Phase 13): Token handling, rotation, and step-up authorization in deployed systems
- Gateways and Registries (Phase 13): Routing, policy enforcement, and registry admission
- Tool Contracts and Content (Phase 13): Schemas, structured content, and content blocks under load
- Reliability and Flow Control (Phase 13): Cancellation races, progress, and timeouts
- Supply Chain and Drift (Phase 13): Registry trust and definition drift detection
- Conformance and Operations (Phase 13): Versioning, conformance tests, and release evidence
Katalock's MCPA prep is independent study material based on the public exam objectives. It is not affiliated with, endorsed by or authorised by the Agentic AI Foundation or the Linux Foundation, does not contain live exam questions, and cannot guarantee a pass. Practice scores are raw percentages over original questions. The official passing score isn't published, so a practice score can't predict an official result.