8.2 · 3.0% of the exam · Topic 2 of 3

MCP Server Development

Build and integrate MCP servers that expose tools, resources, and prompts to Claude applications while choosing appropriate deployment and communication patterns.

Learning objectives

Understand the role and architecture of an MCP server.
Build MCP servers that expose tools, resources, and prompts.
Choose appropriate MCP communication and deployment patterns.
Integrate MCP servers with Claude applications.
Distinguish client-side and server-side responsibilities.
Design MCP servers with clear contracts, validation, and error handling.

Detailed theory

What an MCP server does

An MCP server provides a standardized interface that allows an MCP client to discover and use capabilities exposed by an external system.

An MCP server can expose tools for actions, resources for contextual data, and prompts for reusable interaction patterns.

The server is responsible for implementing its capabilities and communicating through the MCP protocol.

Tools represent executable actions.
Resources represent data or contextual information.
Prompts represent reusable prompt templates or interaction patterns.
The MCP client connects to the server and manages the interaction.

MCP tools

MCP tools allow a Claude application to request an action from an external system through a defined tool interface.

A good MCP tool has a clear name, description, input schema, predictable output, and appropriate error handling.

Keep tool descriptions specific and useful.
Define explicit input schemas.
Validate inputs before performing external actions.
Return useful structured results.
Handle external API and permission errors explicitly.

MCP resources

MCP resources provide access to contextual information or data that an MCP client can retrieve.

Resources are useful when the application needs information rather than an action that changes state.

Use resources for readable contextual data.
Keep resource identifiers predictable.
Control access to sensitive resources.
Avoid exposing unnecessary data.

MCP prompts

MCP prompts provide reusable prompt templates that can be exposed by an MCP server.

They can help standardize common interactions while allowing the client to supply the appropriate arguments.

Use prompts for reusable interaction patterns.
Define clear arguments.
Keep prompt responsibilities separate from tool execution.
Do not use prompts as a replacement for application-level authorization.

Communication patterns

MCP servers can communicate with clients through different transport patterns depending on where the server runs and how the client needs to connect.

Local integrations commonly use stdio, while remote deployments can use network-based transports supported by the MCP implementation.

stdio is useful for local processes launched by a client.
Network transports are useful when the server is deployed separately from the client.
The transport determines how messages move between client and server.
The MCP protocol defines the interaction semantics independently of the underlying deployment environment.

Server-side versus client-side responsibilities

The MCP client is responsible for connecting to MCP servers and presenting their capabilities to the application.

The MCP server owns the implementation of its tools, resources, and prompts and is responsible for interacting with the systems it represents.

Client: connection and protocol interaction.
Server: capability implementation.
Server: external system integration.
Server: input validation and execution errors.
Application: authorization and security boundaries.

Deployment and integration

An MCP server may run locally alongside an application or be deployed as a remote service.

The deployment model affects transport selection, authentication, networking, scaling, observability, and operational responsibilities.

Local servers are useful when the client can launch the server process directly.
Remote servers are useful when multiple clients need access to a shared service.
Remote deployments require appropriate authentication and network controls.
Production servers should provide logging and operational monitoring.

Core concepts

MCP server

What: A server that exposes tools, resources, and/or prompts through the MCP protocol.
Why: It provides a standardized interface between AI applications and external capabilities.
When: When an application needs reusable external capabilities through MCP.
When not: When a simple internal function is sufficient and no MCP integration is required.

MCP tool

What: An executable capability exposed by an MCP server.
Why: It allows the client or model-driven application to request an external action.
When: When the application needs to perform an operation against an external system.
When not: For information that should only be read as contextual data; a resource may be more appropriate.

MCP resource

What: A capability for exposing contextual or readable data through MCP.
Why: It separates data retrieval from executable actions.
When: When the application needs external information or context.
When not: When the primary requirement is to perform a state-changing operation.

MCP prompt

What: A reusable prompt template exposed through an MCP server.
Why: It standardizes common interaction patterns.
When: When multiple clients can benefit from a reusable prompt workflow.
When not: When the requirement is direct external execution or data retrieval.

stdio transport

What: A local communication mechanism using standard input and output streams.
Why: It allows a client to communicate with a locally launched MCP server process.
When: For local MCP server integrations.
When not: When clients need to reach a separately deployed remote server.

Remote MCP server

What: An MCP server deployed separately from the client and accessed over a network.
Why: It allows shared or centralized capabilities to be accessed by clients.
When: When multiple applications or users need access to a shared service.
When not: When a local process is simpler and sufficient.

Practical examples

GitHub MCP server

A Claude application needs to inspect repositories and create issues in GitHub.

An MCP server can expose tools for repository operations while handling the underlying GitHub API integration.

The tool schema should clearly define the repository, issue title, body, and other required inputs.

Company knowledge resource

A company wants Claude to retrieve internal documentation through MCP.

The MCP server can expose documentation as resources while keeping the underlying storage system behind the server boundary.

Access controls should ensure that users only receive documents they are authorized to access.

Remote MCP deployment

Several internal Claude applications need access to the same customer-support system.

Instead of embedding the integration separately into every application, a remote MCP server can provide shared tools for searching and updating support records.

The remote deployment requires appropriate authentication, authorization, networking, logging, and monitoring.

Claude-specific considerations

Claude applications can use MCP servers to access standardized external capabilities.
Tool descriptions and input schemas should clearly communicate what each capability does.
MCP tools should validate inputs before interacting with external systems.
Do not rely on the model alone for authorization of sensitive operations.
Choose local or remote deployment based on connectivity and operational requirements.
Use resources for contextual data and tools for executable actions.

Architecture decisions

SituationChooseBecause

Claude needs to execute an operation against an external API.Expose the operation as an MCP tool.Tools represent executable capabilities.

Claude needs read-only contextual information.Consider exposing the information as an MCP resource.Resources represent accessible data rather than executable actions.

A client needs to launch an MCP server locally.Use a local process communication pattern such as stdio.The server can communicate directly with the locally launched client process.

Several applications need access to one shared MCP integration.Deploy the MCP server as a remote service.A remote service can centralize the integration and make it accessible to multiple clients.

An MCP tool modifies sensitive customer data.Enforce authorization outside the model.Sensitive access control should be an application or service responsibility.

An MCP tool receives malformed input.Validate the input and return a useful error.Server-side validation prevents invalid requests from reaching external systems.

Tradeoffs

MCP architecture involves tradeoffs between deployment simplicity, sharing, operational control, connectivity, and capability boundaries.

AxisLocal / simplerRemote / shared

DeploymentRun the MCP server locally.Deploy the MCP server as a service.

SharingPrimarily available to the local client.Can serve multiple clients.

OperationsLess centralized infrastructure.Requires service operations and monitoring.

ConnectivityLocal process communication.Network communication.

ScalingScale with the local client environment.Can scale the remote service independently.

SecurityLocal process permissions are important.Authentication, authorization, and network controls become important.

Quick reference

MCP servers expose capabilities to MCP clients.
Tools represent executable actions.
Resources represent contextual or readable data.
Prompts represent reusable prompt templates.
stdio is commonly used for local process communication.
Remote MCP servers are useful for shared network-accessible integrations.
Validate MCP tool inputs before calling external systems.
Do not treat Claude as the authorization boundary.

Decision rules for the exam

If the question says…The answer is likely…

"Claude needs to perform an action in an external system"Expose the capability as an MCP tool

"Claude needs read-only contextual data"Consider an MCP resource

"the client launches the server locally"Use a local transport such as stdio

"many clients need the same integration"Consider a remote MCP server

"tool input can be malformed or unsafe"Validate the input on the server

"a tool performs a sensitive operation"Enforce authorization at the application/service boundary

Common exam traps

TrapCorrect answer

MCP resources and tools are the same thing.Tools perform actions; resources provide data or context.

The model should decide whether a sensitive tool call is authorized.Authorization should be enforced by the application or service.

stdio is required for every MCP deployment.Transport should match the deployment and connectivity requirements.

A tool description is enough to validate tool input.The MCP server should validate inputs before execution.

Remote MCP servers do not need authentication because MCP standardizes communication.Remote deployments still need appropriate authentication and authorization.

Open the Domain 8 sheet

Exam tips

Remember the basic distinction: tools execute, resources provide data, and prompts provide reusable interaction templates.
When the question describes a locally launched server, consider stdio.
When multiple clients need shared access, consider a remote deployment.
For sensitive operations, look for explicit authorization outside the model.
Look for server-side validation when the question involves malformed or untrusted tool input.
Choose transport based on deployment and connectivity requirements.

Common mistakes

Using an MCP tool when the requirement is only to retrieve contextual data.
Consider whether an MCP resource is a better representation of the capability.
Putting authorization logic only in the prompt.
Enforce authorization at the application or service boundary.
Assuming all MCP servers must be remote.
Use local deployment when the client can launch the server and local communication is appropriate.
Assuming stdio is appropriate for every deployment.
Choose a transport that matches whether the server is local or remotely deployed.
Trusting MCP tool arguments without validation.
Validate inputs on the server before calling external systems.

Practice questions

Original questions for this topic. They are study items, not questions from the live exam.

Scenario questions

Build exercise

Build a simple MCP server

Intermediate · 45 minutes

What you will learn

Define an MCP server capability.
Create a tool with an explicit input schema.
Validate tool input before execution.
Return useful tool results and errors.
Understand the difference between local and remote deployment.

Step 1
Define the capability
Choose one small external operation such as looking up a customer, listing projects, or retrieving a document.
Why: A focused capability makes the MCP contract easier to understand and test.
You should see: A clearly defined operation with known inputs and outputs.
Step 2
Define the tool contract
Give the tool a clear name, description, and input schema.
Why: The client needs enough information to understand how the tool should be used.
You should see: A tool definition with explicit required and optional fields.
Step 3
Validate input
Validate the incoming arguments before calling the external system.
Why: Invalid input should not reach the downstream API.
You should see: Invalid requests return a clear error without calling the external service.
Step 4
Implement the external call
Connect the MCP tool to the external API or service and map the response into a useful result.
Why: The MCP server owns the external system integration.
You should see: A successful tool invocation returns the expected data.
Step 5
Handle failures
Return useful errors for invalid input, authentication failures, missing records, and downstream service errors.
Why: Clients need actionable information when a tool invocation fails.
You should see: Failure cases produce predictable and understandable responses.

Review checklist

Checks are saved in this browser.

I understand the role of an MCP server.
I can distinguish MCP tools, resources, and prompts.
I understand when local stdio communication is appropriate.
I can explain when a remote MCP server is useful.
I validate MCP tool inputs before execution.
I know authorization should not rely only on model instructions.
I can design useful tool descriptions and schemas.

Key takeaways

MCP servers expose standardized capabilities to MCP clients.
Tools perform actions; resources provide data; prompts provide reusable interaction patterns.
Choose local or remote deployment based on connectivity and operational requirements.
Validate tool inputs before interacting with external systems.
Use explicit application or service authorization for sensitive operations.
Keep external system implementation details behind the MCP server boundary.

Sources

Model Context Protocol — MCP specification, concepts, and server/client documentation.
MCP Documentation — MCP implementation and integration documentation.
Claude Documentation — Claude platform documentation and application guidance.
CCDV-F blueprint notes — Developer certification study reference.

Domain 8 overview · Quick reference

View progress