MCP Servers Explained: How the Model Context Protocol Works

The Model Context Protocol (MCP) is an open standard developed by Anthropic that defines how AI assistants connect to external tools, data sources, and capabilities. Understanding MCP is essential for the CCA-F exam's Domain 2 (Tool Design & MCP Integration, 18% weighting) and increasingly important for any production Claude deployment.

The Three-Layer Architecture

MCP separates concerns across three layers:

• MCP Hosts: Applications that embed Claude (Claude Desktop, Claude Code, your own app). The host manages the lifecycle of MCP clients.
• MCP Clients: Protocol clients that connect to MCP servers. Each client maintains a one-to-one connection with a server.
• MCP Servers: Lightweight programs that expose capabilities (tools, resources, prompts) over the MCP protocol.

This separation means you can build an MCP server once and use it with any MCP-compatible host — Claude Desktop, Claude Code, or a custom application.

The Three Capability Types

MCP servers can expose three distinct capability types. Understanding the difference is a direct exam question:

• Tools: Functions that Claude can call. They have defined input schemas and produce outputs. Tools are model-controlled — Claude decides when to call them.
• Resources: Data sources that can be read. Files, database records, API responses. Resources are application-controlled — the host decides when to load them into context.
• Prompts: Reusable prompt templates with arguments. User-controlled — invoked explicitly, not autonomously by Claude.

Transport Mechanisms

MCP supports two primary transport types:

• stdio: Communication via standard input/output. Used for local MCP servers running as child processes. Simpler to implement and the default for most Claude Desktop integrations.
• HTTP with SSE (Server-Sent Events): Used for remote MCP servers. Enables multi-client connections and remote deployments. Required when the MCP server needs to be shared across users or machines.

The exam tests when to choose each. Local servers with a single user → stdio. Shared infrastructure or remote execution → HTTP/SSE.

The JSON-RPC Protocol

MCP messages are JSON-RPC 2.0. Every tool call is a JSON-RPC request; every tool result is a JSON-RPC response. The key fields are method (e.g., tools/call), params, and id for request/response correlation.

Understanding this matters for the exam because it explains how tool errors propagate. A tool that throws an exception returns an error response with the isError: true flag in the tool result — it does not throw to the Claude API caller. The model receives the error as content and can reason about it.

Tool Input Schema Design

The CCA-F exam's second most common Domain 2 trap is writing inadequate tool descriptions. Claude's tool selection is entirely driven by the description field and the input schema. A tool with a vague description gets called at the wrong time or not at all.

Best practices: describe not just what the tool does, but when to use it and what its limitations are. If a tool only works for read operations, say so. If it requires a specific ID format, document that in the schema.

Security and Injection Defense

Any tool that reads from untrusted sources (web pages, user-provided documents, emails) is a prompt injection vector. Content from those sources could contain instructions designed to hijack Claude's actions. The correct pattern is to treat all tool-returned content as data, not instructions — and to implement hard programmatic gates for sensitive actions rather than relying solely on Claude's reasoning.