Domain 2: Model Context Protocol (MCP)
~18% of CCA exam — approximately 11 questions
Domain 2 of the Claude Certified Architect (CCA) exam is where many candidates stumble. MCP is not a complex protocol in theory, but the exam tests it at the architecture and security design level — not just whether you can recite the three primitive types. The questions ask you to reason about when to use which primitive, how to design secure enterprise MCP deployments, what goes wrong at scale, and how to govern MCP servers in regulated environments.
This study guide covers every testable concept in Domain 2: protocol architecture, the three primitives (Tools, Resources, Prompts), transport types, the Sampling feature, authentication and secret management, multi-server deployment patterns, security threat models, and versioning. Pair it with our 50 CCA practice questions (Q11–Q20 target Domain 2 specifically) and the MCP enterprise guide for production depth.
What MCP Is — and Why It Matters for the CCA
The Model Context Protocol (MCP) is an open standard that defines how AI models connect to external tools and data sources. Before MCP, every integration between Claude and an external system required custom code on both sides. MCP standardises the interface so that any compliant MCP server can expose capabilities to any compliant MCP client — and Claude Cowork, Claude Code, and any Claude API application can be MCP clients.
For the CCA exam, what matters is that MCP is the primary mechanism for extending Claude's capabilities in enterprise deployments. Your Salesforce data, your SharePoint documents, your Jira tickets, your internal analytics platform — all of these become accessible to Claude through MCP servers. Understanding how to architect, secure, and govern MCP deployments is a core competency of a Claude Certified Architect.
If you are deploying Claude through our Claude Cowork deployment service or building integrations via our MCP server development service, MCP architecture is the foundation of everything.
The Three MCP Primitives
MCP defines three types of capabilities that a server can expose. The exam will test your ability to match the right primitive to a given requirement — this is a frequently-appearing question type.
Tools
Callable functions that Claude can invoke to perform actions. Tools may have side effects — they can write data, send messages, call external APIs, or trigger workflows.
Exam signal: "can take action", "side effects", "write", "send", "execute"Resources
Read-only data sources identified by URI. Claude can fetch resource content to include in its context. Resources do not mutate state — they are pure data retrieval.
Exam signal: "read-only", "data source", "documentation", "fetch", "URI"Prompts
Server-defined prompt templates that users or applications can invoke. Prompts are reusable instructions for common workflows — think of them as saved prompt configurations.
Exam signal: "template", "reusable instruction", "workflow prompt", "pre-built"The Primitive Decision Framework — Exam Pattern
- Does it change state? → Tool (sends email, writes to database, creates record)
- Is it read-only data? → Resource (documentation, customer record lookup, product catalogue)
- Is it a reusable prompt structure? → Prompt (code review template, meeting summary format)
- A database query that only reads data can be either Tool or Resource — if the query is parameterised and called dynamically, Tool is more common; if it returns a well-defined dataset by URI, Resource fits
Transport Types: stdio vs HTTP+SSE
MCP supports two transport mechanisms. Choosing correctly is not optional in enterprise environments — it is the difference between a local prototype and a production-grade deployment.
stdio Local Only
Communication over standard input/output. The MCP server runs as a child process of the MCP client on the same machine. Appropriate for Claude Code integrations on developer workstations, local tooling, and testing. Not suitable for remote servers, shared enterprise deployments, or any environment requiring load balancing.
HTTP + Server-Sent Events Enterprise
Communication over HTTP with SSE for server-to-client streaming. Enables remote deployment, load balancing, reverse proxies, standard HTTP authentication middleware, and corporate network infrastructure compatibility. This is the correct choice for all enterprise production MCP servers.
The exam will consistently present scenarios where a team needs to deploy an MCP server for a shared enterprise application (Salesforce, SharePoint, CRM) and ask which transport is appropriate. The answer is HTTP+SSE. stdio is a distractor in enterprise scenarios.
MCP Sampling — The Advanced Feature
Sampling is the most underestimated MCP feature on the CCA exam. Most candidates know the three primitives and the two transports. Fewer understand Sampling well.
Sampling allows an MCP server to request an LLM completion from the host application. In a standard MCP flow, Claude calls a Tool on the MCP server, and the server returns a result. With Sampling, the MCP server can send a completion request back to the host — asking Claude (or whatever LLM the host uses) to reason about something during tool execution. This creates a bidirectional AI loop: Claude reasons about when to call the tool, the tool executes, the tool reasons about the result using Claude, and returns a processed answer.
This enables genuinely agentic MCP servers that don't just execute and return raw data — they analyse, summarise, classify, or decide before returning results to Claude. An MCP server with Sampling can, for example, retrieve 500 customer records, use Claude to identify the 5 most relevant, and return only those 5 — saving Claude's context window and improving response quality.
Sampling — Exam Test Points
- Sampling enables MCP servers to make LLM calls during tool execution
- It creates a server → host → LLM → server loop (bidirectional)
- Primary use case: intelligent pre-processing of large datasets before returning results to Claude
- Sampling requests go to the host application, not directly to the Anthropic API
- Security consideration: Sampling-enabled servers have greater capability and require tighter access controls
Authentication and Secret Management
Authentication is the most heavily-tested security topic in Domain 2. The exam consistently tests the principle that secrets must be managed through dedicated secrets management infrastructure — not stored in code, configuration files, or environment variables in production.
Authentication Patterns
MCP servers connecting to external systems (SaaS APIs, internal services, databases) must authenticate. The two most common patterns are API key authentication (the MCP server holds a service account API key) and OAuth 2.0 (the MCP server uses delegated user credentials or client credentials flow). The correct storage location for both is a dedicated secrets manager: AWS Secrets Manager, Azure Key Vault, HashiCorp Vault, or equivalent.
The exam will present options like "store the token in a config file", "use environment variables", or "hardcode in the server code" and ask which is correct for enterprise production. The answer is always the secrets manager with runtime retrieval. The rationale: secrets managers provide automatic rotation, access auditing, least-privilege access policies, and centralised management — none of which environment variables provide.
User Identity Propagation
Enterprise MCP servers should propagate the authenticated user's identity to downstream systems. When Claude Cowork user Alice calls an MCP server that queries Salesforce, the Salesforce query should execute as Alice — not as a shared service account. This enables row-level security, audit trails, and access control in the downstream system. Implementing user identity propagation typically requires OAuth 2.0 token exchange (the MCP server exchanges Alice's MCP auth token for a Salesforce token scoped to Alice's permissions).
MCP Security Design Principles
Domain 2 includes a substantial security component. You need to understand the threat model for MCP deployments and the controls that address each threat.
-
Input Validation at the Server Boundary
Every parameter received by an MCP server must be validated before being passed to downstream systems. Failing to do so enables SQL injection (if the MCP server builds database queries), command injection (if the server executes shell commands), and SSRF (if the server makes HTTP calls based on user input). Parameterised queries and strict input schema validation are non-negotiable.
-
Human-in-the-Loop for Irreversible Actions
Tools that perform irreversible actions (delete records, send emails, execute payments) must require explicit user confirmation before the MCP server executes the action. This is not optional for enterprise deployments — it is the primary control preventing AI-generated mistakes from causing unrecoverable damage.
-
Least-Privilege Tool Permissions
Each MCP server should have only the permissions required for its defined purpose. An MCP server that reads Salesforce leads does not need Salesforce admin privileges. Service accounts backing MCP servers should have the minimum access required — and that access should be documented, reviewed, and audited.
-
Prompt Injection via External Content
When an MCP Resource returns content from external sources (web pages, emails, documents), that content may contain malicious instructions intended to hijack Claude's behaviour. The defence: clearly mark external content as untrusted data in the tool result, not as instructions; validate Claude's intended actions against the original user request before executing tools triggered by external content.
-
Audit Logging for Compliance
Every tool invocation — including the identity of the requesting user, the tool name, parameters (sanitised of secrets), timestamp, and result — must be logged immutably for audit purposes. In regulated industries, this is a compliance requirement, not just an operational best practice.
Multi-Server Deployment Patterns
Enterprise Claude Cowork deployments commonly include 5-15 MCP servers. This creates architectural challenges that Domain 2 tests directly.
Partial Failure Handling
When a request requires results from multiple MCP servers and one server is slow or unavailable, the naive implementation blocks the entire response. Production architectures must implement per-server timeouts, circuit breakers (stop calling a server that has been repeatedly failing), and graceful degradation (return partial results with clear indication of what data is unavailable). This is one of the most common real-world failure patterns in enterprise MCP deployments.
Tool Naming Conflicts
When two MCP servers expose tools with the same name (e.g., both Salesforce and HubSpot servers expose a create_contact tool), Claude must disambiguate. Best practice is for each MCP server to namespace its tool names with the system name (e.g., salesforce_create_contact and hubspot_create_contact). The exam tests awareness of this naming conflict problem and its solution.
Context Window Budget Management
Multiple tool results from multiple MCP servers can rapidly consume Claude's context window. An enterprise deployment with 8 MCP servers where each returns 2,000 tokens of results could consume 16,000 tokens of context on a single request — before Claude has written a single token of response. Architecture must account for this: implement server-side summarisation, result pagination, and relevance filtering to keep tool results within budget.
Building Enterprise MCP Servers?
Our MCP Server Development service designs and builds production MCP servers with proper authentication, audit logging, error handling, and governance from day one. See how we deploy Claude across enterprise systems.
Versioning and Lifecycle Management
MCP servers are API services. Like all APIs, they evolve — tool schemas change, new tools are added, old tools are deprecated. The CCA exam tests your understanding of how to manage this lifecycle in enterprise environments.
Breaking changes to tool schemas require version management. The recommended pattern is semantic versioning in the server manifest, with a deprecation period where both the old and new versions of a tool coexist. Clients referencing the old schema continue to work while platform teams migrate to the new schema. Abrupt breaking changes without versioning are a production incident waiting to happen.
For non-breaking additions (new optional parameters, new tools), existing integrations continue to work without modification. The server manifest version should follow semver conventions: patch for bug fixes, minor for backwards-compatible additions, major for breaking changes.
Error Semantics — A Frequently-Tested Concept
The distinction between tool errors and empty results is a frequently-tested Domain 2 concept because it directly affects how Claude reasons about the outcome of a tool call.
An error response means the tool invocation failed — authentication error, network timeout, invalid parameters, server crash. Claude should interpret this as "the system didn't work" and respond accordingly: potentially retry, report the failure, or ask for clarification.
An empty result means the tool ran successfully but found no matching data. Claude should interpret this as valid information: "I searched the CRM and found no customers matching your criteria." An empty result is not an error — it is a legitimate answer.
MCP servers that return errors when they mean "no results" (or vice versa) produce incorrect Claude reasoning. The exam tests whether you understand this distinction and can identify the correct implementation choice.
Domain 2 — Top 5 Exam Focus Areas
- Primitive selection: Tool for actions/side-effects; Resource for read-only data by URI; Prompt for reusable templates
- Transport selection: HTTP+SSE for enterprise production; stdio for local development only
- Secret management: Dedicated secrets manager with runtime retrieval — never config files or environment variables
- Human-in-the-loop: Irreversible Tool actions must require explicit user confirmation
- Sampling: Enables MCP servers to make bidirectional LLM calls during tool execution
Test Yourself
Can you answer these before taking the exam? A financial services firm needs an MCP server that fetches a customer's account balance for display — which primitive? (Resource — read-only data by URI.) An MCP server needs to send a wire transfer confirmation email — which primitive, and what oversight control is required? (Tool — with human-in-the-loop confirmation before execution.) An MCP server authenticates to Bloomberg API — where should the Bloomberg API key be stored? (AWS Secrets Manager or equivalent, retrieved at runtime.) A Claude Cowork deployment with 6 MCP servers — what happens if the Salesforce server is down? (Without circuit breakers and graceful degradation, the entire response may block or fail.)
If these are difficult, re-read the relevant sections. For practice questions specifically targeting Domain 2, see questions 11–20 in our 50 CCA practice questions. For broader MCP technical depth, read our MCP enterprise guide and the MCP server Python tutorial for hands-on implementation context.