MCP with Claude: How Model Context Protocol Works

Model Context Protocol (MCP) is an open protocol that lets Claude connect to external services — GitHub, Linear, Notion, and others — without embedding credentials in the agent definition. Claude declares which MCP servers it needs; a separate vault stores the OAuth credentials and injects them at request time, keeping secrets out of your agent configuration entirely.

What is Model Context Protocol?

MCP standardizes how AI models connect to external tool providers. Instead of one-off integrations per service, MCP-compatible servers expose a common interface that Claude can discover and call. In practice, MCP gives Claude access to live, stateful operations: creating a GitHub pull request, querying a Linear board, or updating a Notion page — executed against real systems at inference time.

The protocol is central to the CCA-F exam because it underpins how Claude-powered applications extend beyond text generation into real-world actions. Understanding the MCP architecture — and specifically the security split between agent declarations and session credentials — is expected of anyone designing systems with Claude.

How does Claude connect to an MCP server?

Claude supports MCP through two surfaces: the direct Messages API (in beta, using the mcp-client-2025-11-20 header) and the Managed Agents API. Both follow the same security pattern — declare the server without credentials, then attach credentials separately.

In Managed Agents — the primary path for production Claude applications — the configuration is split across two objects:

• Agent — declares which MCP servers to connect to, by name and URL only. No credentials appear here.
• Session — attaches vaults containing the OAuth tokens for those servers at runtime.

This split means your agent definition is credential-free and safe to version-control. The tokens live in Anthropic-managed vaults and are injected by Anthropic's infrastructure after requests leave the container.

What does an MCP server declaration look like?

When creating an agent, MCP servers are declared at the top level alongside model, system, and tools:

mcp_servers: [
  {
    type: "url",
    name: "github",
    url: "https://api.githubcopilot.com/mcp/"
  }
]

The type: "url" field specifies Streamable HTTP transport — the primary MCP transport Claude currently supports. The name is a local alias referenced when granting tool access:

tools: [
  { type: "agent_toolset_20260401" },
  { type: "mcp_toolset", mcp_server_name: "github" }
]

An agent can declare up to 20 MCP servers. Each mcp_server_name in a toolset entry must match a name in the mcp_servers array. Mismatches produce errors at session-creation time, not silently at runtime.

How does MCP authentication work?

MCP credentials never appear in the agent definition. They live in vaults — Anthropic-managed credential stores that hold OAuth access tokens and, optionally, refresh tokens with a token endpoint for automatic rotation.

A vault credential for an MCP server includes the server URL (used to match the credential to the right declaration), the current access token, and an optional refresh configuration. When a refresh token is provided, Anthropic rotates the access token before it expires — your application code does not manage token lifecycles.

At session creation, you attach vault IDs via vault_ids. Anthropic's orchestration layer matches each vault credential to the declared MCP server by URL. When Claude makes an MCP tool call, the credential is injected after the request leaves the agent container — code running inside the container never sees or can exfiltrate the token. This is a deliberate security boundary: even under prompt injection, a malicious instruction cannot extract vault credentials because they are never present in the container environment.

What happens when Claude calls an MCP tool?

From Claude's perspective, MCP tools appear alongside built-in tools in its available set. When Claude decides to call one, Anthropic's orchestration layer intercepts the outbound request, fetches the matching credential from the vault, adds the authorization header, and delivers the MCP server's response back to Claude.

One design detail worth knowing for the exam: if an MCP tool returns more than 100,000 tokens of output, Claude receives a truncated preview plus a file path it can read using the standard read tool. This auto-offloading prevents a single tool call from flooding the context window on large responses.

Also important: invalid vault credentials do not block session creation. The session starts successfully; a session.error event surfaces the authentication failure only when Claude first attempts to call that MCP server. This matters for debugging — a session that appears healthy can still fail on first MCP tool use if the credential is wrong or missing.

The github_repository resource vs. the GitHub MCP server

A commonly tested pattern is the distinction between the github_repository session resource and the GitHub MCP server. These are complementary, not interchangeable:

• github_repository resource — mounts the repo into the container's filesystem at session startup. Gives Claude file read/write access and git operations (clone, commit, push) authenticated via a git proxy that injects the resource's authorization_token. This token never enters the container.
• GitHub MCP server — gives Claude access to GitHub's REST API: creating pull requests, reading check runs, managing issues. Requires a separate OAuth credential stored in a vault attached to the session.

An agent can edit files in a mounted repo and push a branch using only the github_repository resource. But to open a pull request, the GitHub MCP server must also be declared on the agent, and a vault containing a matching GitHub OAuth credential must be attached to the session. Both are frequently required in the same workflow.

Plinth Prep practice question

This is a Plinth-authored practice item, not a real CCA-F exam question.

A developer builds a Managed Agent with a github_repository resource and declares a GitHub MCP server on the agent. During a session, Claude edits files and pushes commits successfully, but attempting to create a pull request returns an authentication error. What is the most likely cause?

1. The github_repository resource's authorization_token lacks write permissions
2. A vault containing a GitHub MCP OAuth credential has not been attached to the session via vault_ids
3. The MCP server URL must match the github_repository resource URL exactly
4. The agent_toolset_20260401 must be disabled when using an mcp_toolset

Answer: B. Push operations are authenticated through the git proxy using the github_repository resource's token — which is why commits succeed. GitHub API calls, including pull request creation, go through the MCP server and require a separate OAuth credential. That credential must exist in a vault attached to the session via vault_ids. Declaring the MCP server on the agent is necessary but not sufficient — without a matching vault credential on the session, the MCP tool call has no token to use and returns an authentication error.