Anthropic CCA-F: MCP Server Design and Integration
Model Context Protocol gives Claude applications a standardized way to connect with external systems, but a good MCP architecture is more than registering a long list of tools. Claude Certified Architect – Foundations places MCP inside the Tool Design & MCP Integration domain, where the design problem is deciding what capability to expose, how narrowly to expose it, how the client discovers and authorizes it, how much context each interaction consumes, and how the integration fails safely.
On this page
- Understand the MCP client-server model
- Separate tools, resources, and prompts
- Choose a narrow server boundary
- Design model-facing tools well
- Use resources for reference context
- Use prompts as reusable workflows
- Authenticate the real principal
- Apply least authority
- Control context cost
- Design explicit failure behavior
- Treat MCP as a security boundary
- Plan for change and compatibility
- Observe and test the integration
- Review MCP for CCA-F
Understand the MCP client-server model
MCP is an open protocol for connecting AI applications with external systems. An MCP client connects to one or more MCP servers, and each server exposes capabilities the client can make available to the model or user.
This standardization reduces the need to build a completely different integration pattern for every data source or business tool, but it does not remove application-specific security and reliability decisions.
The architect still decides where the server runs, what identity it uses, which data or actions it can reach, what the client is allowed to expose, and how failures are surfaced.
For CCA-F, focus on boundary and design decisions rather than memorizing one installation command or one transport detail.
Separate MCP tools, resources, and prompts by purpose
Tools represent callable actions or operations. A tool can search a system, create an issue, query a database, or perform another operation with defined inputs and outputs.
Resources represent reference information the client can retrieve and place into context. They are useful when the model needs data rather than an action.
Prompts can package reusable instruction patterns or workflows exposed by the server. They are different from tools because they guide the interaction rather than directly execute business logic.
Use the capability type that matches the intent. Turning every piece of information into a tool can make the interface harder to discover and waste context.
Choose an MCP server boundary that matches ownership and risk
A server should expose a coherent capability boundary. Group operations that share an authentication model, data owner, operational lifecycle, and security policy when that makes administration clearer.
Do not create one universal server with broad credentials simply because it is convenient. A single compromise or permission mistake would then inherit the authority of several unrelated systems.
Separate high-impact write capabilities from low-risk read capabilities when policies, reviewers, or operational owners are different.
A clean boundary improves testing because the server can be evaluated against a smaller set of responsibilities.
Design MCP tools as model-facing APIs
Tool names and descriptions help Claude decide when a capability is relevant. Explain what the tool does, what it does not do, important preconditions, and the meaning of parameters.
Use narrow schemas that require the information the operation truly needs. Avoid giant generic payloads that force the model to guess which fields matter.
The Tool Design for Claude Agents guide covers strict schemas, tool search, parallel calls, approval boundaries, and concise structured results.
Return only enough information for the next reasoning step. A tool that dumps thousands of records into context can make the overall agent less reliable even when the API call succeeds.
Use MCP resources for stable reference context
Resources are useful when Claude needs to read or compare information but should not perform a state-changing action.
Design resource identifiers so the client can reference a specific object or collection without forcing the model to scan an entire repository.
Keep access control outside the model. The server should enforce whether the authenticated principal is allowed to retrieve the requested resource.
Large resources should support selection, pagination, filtering, or another context-efficient retrieval strategy rather than assuming every byte belongs in the prompt.
Use MCP prompts for reusable interaction patterns
A server can expose prompts that package a repeatable task pattern, such as reviewing an issue, generating a change summary, or comparing two records.
The prompt should not become a hidden place for privileged authorization rules. Application and server policy still determine which data and actions are permitted.
Keep reusable prompts versioned and test them against representative tasks because changes can affect downstream behavior even when tool schemas remain stable.
Architecturally, prompts can improve consistency while still allowing the client or user to provide task-specific context.
Authenticate the real principal and protect credentials
MCP connectivity does not eliminate authentication. The server still needs to know which user, service, organization, or workload is making the request.
Avoid broad shared credentials when the external system can support scoped user or workload identity. Shared secrets make attribution and revocation harder.
Store credentials outside prompts, tool descriptions, source code, and ordinary logs. The model usually needs the capability, not the secret itself.
Remote MCP services should use an authentication and transport design appropriate to the exposed data and actions, then enforce authorization on every request.
Apply least authority to clients, servers, and tools
The MCP server should have only the upstream permissions it needs, and the client should expose only the capabilities appropriate to the workflow.
High-consequence tools can require explicit user or policy approval before execution. Read-only access, low-risk writes, and destructive changes do not need identical approval behavior.
Separate discovery from authorization. A model may know a tool exists without automatically having permission to execute every operation it describes.
Review stale servers and capabilities. An integration that is no longer used should not retain credentials or access simply because it remains configured.
Control context cost as the MCP catalog grows
Large tool catalogs can consume context through names, descriptions, schemas, and server instructions before useful work begins.
Current Claude tooling supports patterns such as deferred tool discovery or tool search so relevant definitions can be loaded when needed rather than placing every definition in context up front.
Design descriptions to be concise but discriminative. If several tools have vague overlapping descriptions, the model may choose poorly even when all schemas are correct.
Context efficiency is an architecture concern because bloated tool metadata competes with user instructions, evidence, retrieved data, and working state.
Design failure behavior that an agent can reason about
An MCP tool should distinguish invalid input, authorization failure, missing data, transient upstream failure, rate limiting, and a successful request with no matching result.
Return errors that help the client decide whether to retry, ask the user for more information, choose another path, or stop.
Do not hide partial failure behind a generic success response. If an operation updated one system but failed in another, the orchestrator needs to know the actual state.
Bound retries and use idempotency where appropriate so recovery does not duplicate state-changing actions.
Treat MCP as a security boundary, not only an integration convenience
An MCP server can expose sensitive data and privileged actions to an AI client, so its security posture should be reviewed like any other service boundary.
Threat-model server compromise, credential theft, malicious or misleading tool descriptions, overbroad upstream access, and untrusted content returned through resources or tools.
Use network and identity controls appropriate to the environment, keep dependencies supported, and monitor unusual capability use.
A convenient integration is not a justification for bypassing normal security architecture. MCP should inherit the same ownership, least-privilege, logging, and incident-response expectations as other production interfaces.
Plan for protocol, server, and upstream change
An MCP server depends on the protocol, its own implementation, external APIs, schemas, authentication, and the client environment. Any of those can change independently.
Version breaking server behavior deliberately and test compatibility with the clients that matter to the organization.
Keep tool names and semantics stable when possible because renaming or repurposing a capability can invalidate prompts, evaluations, and operator expectations.
Document deprecation and migration so old credentials, endpoints, or capabilities do not remain active indefinitely.
Observe and test the integration as a complete system
Test discovery, authentication, authorization, schemas, resource retrieval, tool execution, error paths, and context behavior rather than validating only the server API in isolation.
Use synthetic or nonproduction accounts for destructive-path testing. Verify that disallowed actions fail even if the model requests them correctly.
Log enough to connect a user or workflow, MCP server, capability, upstream system, and outcome without exposing secrets.
Measure task success, not only server uptime. An MCP server can be technically available while poor descriptions or excessive context make the agent perform badly.
Review Tool Design & MCP Integration for CCA-F
Know the client-server model and the purpose of tools, resources, and prompts.
Design narrow capability boundaries, enforce real authentication and authorization, protect credentials, control context cost, and make errors explicit.
Use tool descriptions and schemas as part of the model interface, then keep business policy and permission enforcement outside the model.
For Domain 2, be ready to explain not only how MCP connects systems, but how an architect keeps that connection useful, least-privileged, observable, and reliable.