MCP Server Integration into Claude Code and Agent Workflows

The MCP server integration topic is the entry point into Claude Code's most distinctive extensibility surface on the CCA-F exam. Task statement 2.4 — "Integrate MCP servers into Claude Code and agent workflows" — sits inside Domain 2 (Tool Design & MCP Integration, 18% of the exam) and anchors the two most exam-relevant scenarios: Developer Productivity with Claude and Code Generation with Claude Code. Candidates who cannot reason about MCP server integration scoping, credential handling, or the MCP tool vs MCP resource distinction routinely lose four to six points on an exam where the passing line is already tight at 720/1000.

This study note walks through the full MCP server integration surface an architect is expected to recognize: the Model Context Protocol itself, the project-level .mcp.json file versus the user-level ~/.claude.json file, how environment variable expansion keeps secrets out of version control, how Claude Code discovers and merges tools from all configured MCP servers at connection time, the structural difference between MCP tools and MCP resources, the decision criteria for adopting existing community MCP servers versus authoring custom ones, and the often-overlooked lever of enhancing MCP tool descriptions so the agent prefers them over built-ins. Every section is written at CCA-F recognition depth — architectural judgment, not implementation code.

What Is the Model Context Protocol and Why Does Claude Code Use It?

The Model Context Protocol (MCP) is an open specification for connecting AI assistants to external systems — databases, APIs, file stores, issue trackers — through a uniform message interface. Before MCP, every AI client had to invent its own plugin format, and every tool provider had to ship a different adapter for each client. MCP collapses that N × M integration matrix into N + M: one server implementation works with every MCP-aware client, and one client can reach every MCP server. The official MCP specification describes the design as "USB-C for AI applications" because any compliant plug fits any compliant socket.

Claude Code is one of the most MCP-native clients in production today. A Claude Code session can connect to multiple MCP servers simultaneously and merge their tool catalogs into the single tool list Claude reasons about during the agentic loop. MCP server integration therefore is not an optional add-on for Claude Code architects — it is the primary mechanism by which real engineering teams extend Claude Code beyond its built-in Read / Write / Edit / Bash / Grep / Glob tools into their internal systems.

The Three MCP Primitives at a Glance

An MCP server integration exposes some combination of three primitives:

• MCP tools — callable functions with side effects. Example: create_jira_ticket, run_sql_query, send_slack_message.
• MCP resources — readable content addressed by URI. Example: jira://issue/PROJ-123, db://schema/orders, docs://handbook/deployment.
• MCP prompts — reusable prompt templates the client can insert. Example: a "bug-triage" prompt that pre-fills investigation steps.

The CCA-F exam consistently tests the tools vs resources distinction. Candidates who treat every MCP capability as a "tool" miss questions that ask "which primitive exposes a catalog of content the model can browse before calling tools?" — the answer is always resources.

Why MCP Exists in the CCA-F Blueprint

Domain 2 weights MCP integration at 18%, and task 2.4 specifically targets Claude Code integration. The community exam reports (Kukreja 893/1000, Hightower complete guide, McRolly technical roadmap) all flag MCP tool boundaries and scoping as a high-frequency trap (pain point pp-12). A candidate who understands why the protocol exists — interoperability, least-privilege extension, separation of server concerns from client concerns — reasons about scoping and credential questions correctly without memorizing flags.

Project Scope vs User Scope: .mcp.json vs ~/.claude.json

The single most tested aspect of MCP server integration on the CCA-F exam is scoping. Claude Code reads MCP server definitions from two locations, and the choice between them has direct consequences for team collaboration, credential safety, and configuration drift.

Project Scope — .mcp.json in the Repository Root

When a file named .mcp.json sits in the root of a Claude Code workspace (typically the repository root), Claude Code loads the MCP servers it declares every time a session starts in that workspace. Because .mcp.json is committed to the repository, every developer on the team, every CI runner, and every automated agent that clones the repo gets the identical MCP server list. Project scope is the correct choice for shared team tooling: a Jira server the whole team queries, a database schema server backing a shared analytics workflow, a staging-environment deployment server used by the release pipeline.

User Scope — ~/.claude.json in the Home Directory

A second MCP configuration lives at ~/.claude.json in each developer's home directory. Entries here are personal — they apply to every Claude Code session the user starts, on every repository, but they are never shared with teammates. User scope is the correct choice for developer-specific tooling: a personal note-taking server, a private bookmark manager, an experimental MCP server under active development, or a credential-heavy integration the developer does not want the rest of the team to see.

Choosing Between Project and User Scope

The decision rule the exam tests is crisp:

• Shared with the team? → project scope (.mcp.json).
• Personal or experimental? → user scope (~/.claude.json).

Architectural mistakes happen in both directions. Putting a team-shared Jira server in user scope forces every developer to re-install it manually and produces configuration drift ("why does my Claude Code not see the Jira tools?"). Putting a personal experimental server in project scope pollutes every teammate's tool list with something they did not ask for and cannot use.

Why Both Scopes Can Be Active Simultaneously

Claude Code merges servers from both files at session start. If a developer has both a project-level .mcp.json declaring a Jira server and a user-level ~/.claude.json declaring a personal notes server, the running session sees both server's tools. The merge is additive, not exclusive, so user-scope entries never override or conflict with project-scope entries unless they use the same server name. Architects should pick names that telegraph scope (team-jira, personal-notes) to prevent accidental shadowing.

Environment Variable Expansion: Keeping Secrets Out of .mcp.json

Because .mcp.json is committed to version control, it must not contain credentials. Hard-coding a GitHub personal access token, a Jira API key, or a database password into .mcp.json leaks the secret to every repository clone, every fork, and every GitHub search that crawls the diff. This is one of the highest-severity mistakes in MCP server integration, and the CCA-F exam tests it directly.

The ${VAR_NAME} Expansion Syntax

Claude Code supports environment variable expansion inside .mcp.json entries. Any string of the form ${VAR_NAME} is replaced with the value of the environment variable VAR_NAME at session start. The canonical pattern:

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_TOKEN": "${GITHUB_TOKEN}"
      }
    }
  }
}

The file committed to the repository contains only the placeholder ${GITHUB_TOKEN}. Each developer sets GITHUB_TOKEN in their own shell environment (via .envrc, direnv, 1Password CLI, or a secret manager integration), and Claude Code resolves the variable at runtime. No secret ever enters the repository.

Credential Handling Patterns That Scale

For a small team, direnv plus a .envrc file (git-ignored) is enough. For a larger organization, the pattern becomes:

• Developer machines → 1Password CLI or AWS Secrets Manager → environment variables → .mcp.json expansion.
• CI runners → GitHub Actions Secrets or GitLab CI variables → environment variables → .mcp.json expansion.
• Shared CLAUDE.md documents the required variable names so every developer can onboard without guessing.

This layering means the .mcp.json file itself stays stable and reviewable, while the secret surface moves to whichever secret manager the organization already trusts.

How Claude Code Discovers Tools at Connection Time

An architect reasoning about MCP server integration must understand the session lifecycle. When Claude Code starts a session, it performs the following sequence:

1. Read .mcp.json from the workspace root (if present).
2. Read ~/.claude.json from the user home directory (if present).
3. Merge the two server lists into one connection plan.
4. Spawn each stdio server (or dial each remote server) in parallel.
5. For every successfully connected server, query its tool catalog via the MCP tools/list method.
6. Query each server's resource catalog via resources/list.
7. Concatenate all discovered tools into a single list alongside Claude Code's built-in tools.
8. Present the combined list to Claude for the duration of the session.

Two architectural consequences matter for the exam:

Tools from All Configured Servers Are Simultaneously Available

Once discovery completes, Claude sees every tool from every connected MCP server plus every built-in tool as one flat list. There is no per-turn filtering of which servers Claude can reach — if a server is connected, all of its tools are reachable. This is why distributing tools across agents (task 2.3) matters: an agent with too many simultaneous MCP servers ends up with hundreds of tools in its context, which both inflates token cost and degrades Claude's routing accuracy.

Discovery Happens Once Per Session

MCP tool discovery is a connection-time operation. If you add a new MCP server entry to .mcp.json mid-session, Claude Code does not see it until the next session starts. This matters for long-running automated workflows: design the configuration for the whole session, not for incremental additions.

MCP Tools vs MCP Resources: The Primitive Distinction That Moves Points

The MCP tools vs MCP resources distinction is the single most under-studied topic in Domain 2, and the CCA-F exam tests it in almost every sitting.

MCP Tools

An MCP tool is a callable function with side effects or computational output. Calling a tool costs a full agentic-loop round trip: Claude emits stop_reason: "tool_use", the client executes the tool, the result comes back as a tool_result block, and Claude continues. Tools are how agents do things — create a ticket, run a query, send a message, execute a script.

MCP Resources

An MCP resource is a readable content unit addressed by a URI. Resources are how servers expose catalogs of content — issue summaries, documentation hierarchies, database schemas, file trees — that the model can browse without paying the full tool-call cost. A well-designed MCP server exposes resources for content the model wants to read and tools for operations the model wants to perform.

Why Resources Reduce Exploratory Tool Calls

Consider a Jira MCP server that exposes only tools: search_issues(query), get_issue(id), create_issue(...), update_issue(...). When Claude wants to find the right ticket to update, it has to guess keywords for search_issues, inspect a handful of candidates, re-guess, and iterate. Each of those iterations is a full tool-call round trip.

Now consider the same server exposing an issue catalog resource at jira://project/PROJ/open-issues that returns a compact list of open tickets with IDs, titles, and status. Claude can read that resource once at the start of the conversation, identify the relevant ticket by pattern-matching against the user's request, and call get_issue(id) or update_issue(...) directly — zero guesswork. Fewer tool calls, lower token cost, higher accuracy.

The same pattern applies to documentation hierarchies (one resource returns the table of contents; tools fetch specific pages) and database schemas (one resource returns the schema overview; tools run specific queries).

Exam Cue: "Reduce Exploratory Tool Calls"

When a CCA-F scenario says "the agent makes many speculative search calls before finding the right record," the fix is almost always "expose a catalog as an MCP resource so the agent can browse before calling tools." Answer choices that propose "add more tools" or "increase the search tool's limit parameter" miss the architectural insight.

Plain-Language Explanation: MCP Server Integration

Abstract protocol design becomes concrete when anchored to physical, everyday systems. Three very different analogies cover the full sweep of MCP server integration concepts.

Analogy 1: The Kitchen — Tools, Resources, and Servers

Imagine Claude Code as a head chef running a kitchen. The chef's built-in tools are the knives, pans, and stove that come with the kitchen — Read, Write, Edit, Bash, Grep, Glob. MCP servers are specialty stations wheeled in on demand: the pasta extruder station (a Jira server), the pastry station (a database server), the sous-vide station (a deployment server). Each station arrives with its own set of MCP tools — the pasta extruder's button, the sous-vide's temperature knob — that the head chef can operate.

The distinction between MCP tools and MCP resources maps to the same kitchen. The pasta extruder does something when you press its button (that is a tool). The laminated recipe book bolted to the side of the station, which the chef can read without pressing anything, is a resource. A well-equipped station always comes with both: the recipe book tells the chef what the station is for; the buttons actually produce the pasta.

Project scope (.mcp.json) is the kitchen's shared equipment list bolted to the wall — every cook on every shift sees the same stations. User scope (~/.claude.json) is the personal kit a chef carries in their own roll — a favorite microplane, a custom thermometer — that goes home with them at night. Environment variable expansion is the safe where credentials (the walk-in freezer key, the liquor license) live; the equipment list on the wall references "the key in the safe" rather than printing the key itself.

Analogy 2: The Library — Resources vs Tools for Content Discovery

A library analogy sharpens the resource-vs-tool distinction. Imagine you walk into a reference library looking for a specific book. The library offers two ways to find it.

The tool-only approach is to walk up to the reference desk and ask the librarian to search for books by keyword. Every search is a round trip — you state keywords, the librarian disappears into the stacks, returns with candidates, and you re-query. Miss the right keyword and you loop endlessly.

The resource-plus-tool approach is the card catalog at the entrance — a browsable index you can scan yourself to find the exact Dewey Decimal number, and then ask the librarian to fetch that specific book. The card catalog is an MCP resource: a readable content surface that reduces the number of times you need to pester the librarian (tool). Any well-designed library combines both.

This analogy directly maps to the Jira example. A tool-only Jira integration forces Claude to keep guessing search keywords. A Jira integration that exposes the open-issue catalog as a resource lets Claude browse the list, identify the right ticket, and make one surgical tool call to update it.

Analogy 3: The Open-Book Exam — Scope, Credentials, and Discovery

An open-book exam analogy covers scoping and credential handling. Every student (developer) shows up with two binders. The course-issued binder (project scope — .mcp.json) is identical for every student: it contains the formulas, reference tables, and shared materials the whole class is allowed to use, committed to a shared syllabus. The personal binder (user scope — ~/.claude.json) is each student's own notes: annotations, personal mnemonics, practice scratchpad. No two students' personal binders are identical.

Neither binder is allowed to contain the answer key (credentials). The answer key is sealed in the proctor's envelope; each student is told at the start of the exam, "if you need the answer to problem 7, the reference code is ${PROBLEM_7_KEY}, and the proctor will read it out to you." That is environment variable expansion: the committed binders reference the secret by name, not by value.

Discovery at connection time is the rule that the student can only use binders they brought into the exam room at the start. If a student realizes mid-exam that they forgot a binder, they cannot leave to fetch it — they work with what they have until the next sitting (next Claude Code session).

Which Analogy to Use on Exam Day

• Questions about MCP tools vs MCP resources → library analogy.
• Questions about project vs user scope, credentials, environment variables → open-book-exam analogy.
• Questions about how servers combine into one agent's tool list → kitchen analogy.

Community MCP Servers vs Custom Implementations

Architecture questions on CCA-F repeatedly frame the choice between adopting an existing community MCP server and building a custom one from scratch. The principled answer is almost always "use the community server for standard integrations, reserve custom for team-specific workflows."

Why Community Servers Win for Standard Integrations

Anthropic, the MCP community, and third-party vendors maintain MCP servers for the most common integration targets: GitHub, Jira, Slack, Linear, Google Drive, PostgreSQL, Notion, Sentry. These servers are:

• Battle-tested — deployed across thousands of Claude Code installations, edge cases already filed and fixed.
• Spec-compliant — implement the MCP protocol correctly, including pagination, error shape, and resource URIs.
• Maintained — track API changes in the upstream system (GitHub API v4 migration, Jira Cloud schema updates) so your team does not have to.
• Discoverable — appear in MCP directories and are recognizable by their @modelcontextprotocol/ or well-known vendor npm packages.

For a standard "create a Jira ticket from a Claude Code session" workflow, using the community Jira server is the right architectural choice. Writing a custom Jira MCP server duplicates months of work, introduces new maintenance burden, and almost always ships with worse error handling than the community version.

Why Custom Servers Win for Team-Specific Workflows

The community cannot maintain servers for your internal systems. If your team has:

• A bespoke internal tool (deployment orchestrator, internal CMS, proprietary analytics platform) with no public API surface that matches a standard MCP server;
• A domain-specific workflow that combines several internal systems into one logical operation ("create a customer incident ticket, link it to the on-call rotation, and post a summary to the incident channel");
• A compliance-sensitive integration that must run inside a specific network boundary or under specific audit controls;

...then a custom MCP server is the right call. The custom server encapsulates the team's internal complexity behind a clean MCP interface, and every Claude Code session across the team automatically inherits the capability.

The Decision Rule the Exam Tests

The CCA-F scenario usually signals the correct choice through a single phrase:

• "Integrating with Jira / GitHub / Slack / PostgreSQL" → community MCP server.
• "Integrating with the team's internal deployment system" → custom MCP server.
• "The team is evaluating several options" → community if one exists, custom only if none does.

Enhancing MCP Tool Descriptions So the Agent Prefers Them Over Built-Ins

A subtle but heavily tested lever in MCP server integration is the tool description. Claude Code's built-in tools (Read, Write, Edit, Bash, Grep, Glob) have well-tuned descriptions that make them the default routing target for generic file and shell operations. When an MCP server adds a new tool whose description is weaker or vaguer, Claude tends to fall back to the built-in — even when the MCP tool is the architecturally correct choice.

The Tool-Description-as-Routing-Mechanism Principle

This matches the broader Domain 2 pain point (pp-02): tool descriptions are routing mechanisms. When two tools overlap, Claude routes to whichever description more specifically describes the current task. A custom MCP tool called deploy_service with the description "Deploy a service" will lose routing contests to Bash with its well-tuned description that names its use cases explicitly. A rewritten description — "Deploy a named service to the company's Kubernetes cluster via the internal rollout controller; use this for any deployment task instead of running kubectl or helm directly; accepts service name and target environment; returns deployment status and rollback instructions" — wins the routing contest because it tells Claude when to prefer this tool.

Description Tuning Checklist

A production-quality MCP tool description should include:

• A one-sentence purpose statement that names the specific domain ("the company's Kubernetes cluster," not "a cluster").
• Explicit boundaries vs built-in tools ("use this instead of running kubectl directly") so Claude knows when to override the default.
• Input format examples with at least one concrete example.
• Edge cases and failure modes ("returns 503 during active rollouts; retry after 60 seconds").
• Output shape so Claude can chain subsequent tools correctly.

The Exam Cue

When a CCA-F scenario says "Claude keeps running raw kubectl commands through Bash instead of using our custom deploy_service MCP tool," the fix is to rewrite the MCP tool's description to explicitly tell Claude to prefer it over Bash for deployment tasks. Answer choices that propose "restrict the Bash tool" or "remove Bash from the allowlist" are wrong — they introduce fragility. The lightweight, durable fix is better tool descriptions.

Remote MCP Servers and the MCP Connector for the Messages API

Although CCA-F focuses on Claude Code, architects should recognize the adjacent surface of remote MCP servers reachable from the Messages API. The MCP connector is a public-beta capability that lets a Messages API request specify an MCP server URL; Anthropic's infrastructure connects to that server on the client's behalf and exposes its tools in the ongoing conversation.

Why Remote MCP Matters Architecturally

Remote MCP means an MCP server built for Claude Code can, with minimal additional work, be reused by server-side Messages API applications. The server becomes an organizational capability rather than a per-client integration. CCA-F may surface this in cross-domain scenarios: "the team already has a Jira MCP server running for Claude Code; can they reuse it from their customer-support application built on the Messages API?" — yes, through the MCP connector.

Out of Scope for CCA-F Foundations

The CCA-F exam does not test MCP server deployment and hosting (Kubernetes topology, load balancing, TLS termination). Those concerns belong to infrastructure engineering, not architectural foundations. Stay inside the protocol, scoping, and configuration surface — that is where the exam points live.

Common Exam Traps: Scoping, Credentials, and Primitive Confusion

The CCA-F exam concentrates five recurring MCP server integration traps.

Trap 1: Confusing Project Scope and User Scope

Answer choices flip the file locations. .mcp.json is project scope, committed to the repository; ~/.claude.json is user scope, in the home directory, never committed. Any option that reverses this is wrong.

Trap 2: Literal Credentials in .mcp.json

Any snippet that writes a secret as a literal string into .mcp.json is wrong, even if surrounding text claims the secret is low-privilege or temporary. The correct pattern is always ${VAR_NAME} environment variable expansion.

Trap 3: Treating MCP Resources as Tools

Scenarios about browsing a catalog of issues or documentation pages resolve to resources, not tools. Candidates who answer "add a list_issues tool" miss that MCP resources already solve this problem natively with lower token cost.

Trap 4: "Build a Custom MCP Server" When a Community One Exists

Reaching for custom implementation on standard integrations (Jira, GitHub, Slack, Postgres) is always the wrong default. Custom is reserved for team-specific workflows with no community equivalent.

Trap 5: Restricting Built-in Tools Instead of Improving Descriptions

When Claude prefers a built-in tool over a custom MCP tool, the fix is rewriting the MCP tool description to win routing — not removing the built-in from the allowlist. Removing built-ins introduces fragility; better descriptions are the durable fix.

Distinction Note: CCA-F Recognition vs Advanced MCP Implementation Depth

CCA-F is positioned as a foundational Anthropic certification for architects with 6+ months of hands-on Claude experience. It tests recognition-level competence with the MCP server integration surface — can you identify the right scope, the right primitive, the right credential pattern, and the right build-vs-adopt choice?

Deeper MCP implementation topics — authoring a production MCP server from scratch, designing custom authentication flows, optimizing stdio transport performance, deploying remote MCP servers under load — belong to advanced practice rather than CCA-F.

What CCA-F Expects of You

• Distinguish .mcp.json (project) from ~/.claude.json (user) scope.
• Apply environment variable expansion to keep credentials out of version control.
• Recognize that MCP tools are discovered at session start and available simultaneously.
• Tell MCP tools from MCP resources by the "doing vs reading" signal.
• Default to community MCP servers for standard integrations; reserve custom for team-specific workflows.
• Improve MCP tool descriptions to win routing over built-in tools.

What CCA-F Does NOT Expect of You

• Code a full MCP server implementation in TypeScript or Python.
• Configure Kubernetes ingress for a remote MCP server.
• Author a custom MCP transport beyond stdio and HTTP.
• Derive the JSON-RPC wire-format specification from scratch.
• Design an MCP server authentication scheme from first principles.

If you find yourself studying MCP server deployment topologies or authentication flow diagrams, you have drifted beyond CCA-F scope — redirect to architectural-judgment depth and move on.

Practice Anchors: Task 2.4 Scenario Question Templates

CCA-F practice questions tied to MCP server integration cluster into five shapes. Detailed questions with full explanations live in the ExamHub question bank.

Template A: Scope Placement

A team has decided to standardize on a shared Jira MCP server so every engineer's Claude Code session can create and update tickets. Where should the MCP server be configured? Correct answer: project scope, in .mcp.json committed to the repository root. Distractors claim user scope (defeats the "every engineer" signal) or global installation (not how Claude Code scoping works).

Template B: Credential Safety

A developer proposes committing a GitHub personal access token directly into .mcp.json "to make onboarding easier for new engineers." Which approach is correct? Correct answer: use ${GITHUB_TOKEN} environment variable expansion in .mcp.json and document the variable in the team's onboarding guide. Distractors include "commit the token since it is low-privilege" (never acceptable) and "store the token in the repository's secrets file" (same leak, different name).

Template C: Primitive Selection

A team's Claude Code agent repeatedly makes speculative search_issues calls with guessed keywords before finding the right Jira ticket to update. Which MCP capability should the server add to reduce exploratory tool calls? Correct answer: an MCP resource exposing the open-issue catalog (e.g., jira://project/PROJ/open-issues), which the agent can read once before calling tools. Distractors propose "add more search tools" or "increase the search tool's limit parameter" — neither addresses the architectural root cause.

Template D: Build vs Adopt

A team wants to integrate Claude Code with their PostgreSQL database for schema queries. A community MCP server for PostgreSQL already exists and is widely used. Which is the correct architectural choice? Correct answer: adopt the community PostgreSQL MCP server. Distractor claims "build a custom server for tighter control" — wrong default unless the scenario explicitly rules out community options.

Template E: Tool Description Tuning

Claude keeps running raw kubectl commands through the built-in Bash tool instead of using the team's custom deploy_service MCP tool. Which fix is most appropriate? Correct answer: rewrite the deploy_service tool description to explicitly name its purpose, boundaries vs Bash, inputs, and output shape so Claude prefers it for deployment tasks. Distractors propose removing Bash from the allowlist (fragile) or adding a CLAUDE.md rule (less durable than a well-tuned description).

MCP Server Integration Frequently Asked Questions (FAQ)

What is the difference between .mcp.json and ~/.claude.json on the CCA-F exam?

.mcp.json lives in the repository root and is committed to version control; it defines MCP servers shared by the whole team. ~/.claude.json lives in the user's home directory and is never committed; it defines MCP servers personal to one developer. Project scope (.mcp.json) is correct for team-shared integrations (Jira, GitHub, internal deployment tools). User scope (~/.claude.json) is correct for personal, experimental, or credential-sensitive servers that should follow the developer rather than the project. Both files are read at session start and their server lists are merged into one tool catalog.

How do I keep credentials out of .mcp.json when it is committed to the repository?

Use environment variable expansion: wherever the MCP server configuration needs a credential, write it as ${VAR_NAME} rather than a literal string. Claude Code resolves the placeholder from the shell environment at session start. Developers set the variables locally via direnv, .envrc, 1Password CLI, or their organization's secret manager. CI runners inject them via pipeline secrets. If the variable is missing at session start, Claude Code reports an MCP server startup error rather than silently expanding to an empty string. Never commit literal tokens even as a placeholder — once a secret enters git history, it must be rotated.

Are all MCP server tools available to Claude at once, or does Claude pick one server per turn?

All tools from all connected MCP servers are available simultaneously for the entire session. At session start, Claude Code connects to every server declared in .mcp.json plus every server in ~/.claude.json, queries each server's tool and resource catalog, and merges everything into one flat list alongside the built-in tools (Read, Write, Edit, Bash, Grep, Glob). There is no per-turn server selection — Claude sees the full catalog for the duration of the session. This is why architects must be careful about tool count: an agent with too many connected MCP servers ends up with hundreds of tools in context, inflating token cost and degrading routing accuracy.

What is the difference between an MCP tool and an MCP resource?

An MCP tool is a callable function with side effects — calling it triggers a full agentic-loop round trip (stop_reason: tool_use → client executes → tool_result block → Claude continues). Tools are how agents do things: create a ticket, run a query, send a message. An MCP resource is a readable content unit addressed by URI (jira://issue/PROJ-123, db://schema/orders) — it exposes a catalog of content the model can browse without paying the full tool-call cost. A server that exposes its issue catalog as a resource reduces exploratory tool calls because the model can read the catalog directly before deciding which tool to invoke. Well-designed MCP servers offer both primitives.

When should I build a custom MCP server instead of using a community one?

The correct architectural default is use the community MCP server for standard integrations (Jira, GitHub, Slack, Linear, PostgreSQL, Notion, Sentry) and reserve custom implementations for team-specific workflows with no community equivalent. Community servers are battle-tested, spec-compliant, maintained against upstream API changes, and discoverable. Building a custom version of an existing community server duplicates months of work and ships with worse error handling. Custom is the right call when integrating bespoke internal systems, combining several internal systems into one logical operation, or satisfying compliance requirements the community server does not meet.

Why does Claude Code sometimes ignore my custom MCP tool and use a built-in tool instead?

Because the tool description is the routing mechanism Claude uses to choose between overlapping tools. Built-in tools like Bash and Read ship with well-tuned descriptions that win routing contests against weakly-described custom tools. The fix is almost never to restrict the built-in tool — that introduces fragility. The durable fix is rewriting the custom MCP tool description to name its specific purpose, its boundaries vs built-in tools ("use this instead of running kubectl directly"), its input format with examples, and its output shape. A specific, boundary-aware description wins the routing contest and becomes Claude's preferred choice.

Does the CCA-F exam test MCP server deployment and hosting?

No. CCA-F Domain 2 task 2.4 tests integration — how to configure, scope, credential, and use MCP servers from Claude Code — not deployment. Topics like Kubernetes ingress for remote MCP servers, TLS termination, horizontal scaling, and custom transport protocols are out of scope. The exam also does not test fine-tuning, vision, streaming API details, or cloud-provider-specific configurations. Stay inside the protocol, scoping, and configuration surface where the exam points live.

Further Reading

• Claude Code MCP Integration Docs: https://docs.anthropic.com/en/docs/claude-code/mcp
• Model Context Protocol Introduction: https://modelcontextprotocol.io/introduction
• MCP Build a Server Guide: https://modelcontextprotocol.io/docs/develop/build-server
• MCP Connector for the Messages API: https://docs.anthropic.com/en/docs/agents-and-tools/mcp-connector
• Anthropic Engineering — Writing Tools for Agents: https://www.anthropic.com/engineering/writing-tools-for-agents
• Claude Code Tool Reference (Built-in Tools): https://docs.anthropic.com/en/docs/agents-and-tools/tool-use/tool-reference
• CCA-F Exam Guide: https://everpath-course-content.s3-accelerate.amazonaws.com/instructor/8lsy243ftffjjy1cx9lm3o2bw/public/1773274827/Claude+Certified+Architect+%E2%80%93+Foundations+Certification+Exam+Guide.pdf

Related ExamHub topics: Tool Design and MCP Integration Overview, Structured Error Responses for MCP Tools, Claude Code Built-in Tools, CLAUDE.md Configuration Hierarchy, Tool Descriptions as Routing Mechanisms.