What you will be able to do
- Tell apart the parts an MCP integration is built from (host, client and server) and what the protocol standardises between them
- Explain how direct tool use works, where your application defines and runs the tool, and when that is enough
- Know what the Messages API MCP connector does, what it needs and what it cannot do, so you can tell when it fits
Key concept
Integration mechanism — The integration mechanism is your decision about who defines a capability, where its code runs and who owns the connection. The choices are your own application (direct tool use through the API), an MCP server that Claude reaches through a client such as the connector, or another agent that runs in its own context. Most exam scenarios become easy once you ask where the code executes and who has to write the client.
1.Three ways to give Claude a capability
The exam guide names three integration mechanisms: MCP, API/CLI, and agent-to-agent. They are not competing brands. Each one answers the same question differently: when Claude needs something it cannot do from its own weights, who provides that capability, and over what connection?
With direct tool use, you describe a function in the API request. Claude returns a structured call, and your application runs it. That application may call a REST API or run a command-line tool. With MCP, a separate server exposes its capabilities through a shared protocol, and a client connects to that server. With agent-to-agent delegation, the capability is a whole other agent, with its own model, prompt and tools.
This page covers the first two, because the most common exam decision is between them. The MCP specification describes three roles. The client is not the application itself. It is a connector that lives inside the application.
| Role | What the specification says it is |
|---|---|
| Hosts | LLM applications that initiate connections |
| Clients | Connectors within the host application |
| Servers | Services that provide context and capabilities |
2.What MCP standardises, and what it isolates
MCP messages use JSON-RPC. The specification defines three message types: requests that expect a response, responses that match a request ID, and one-way notifications. A connection is stateful. The host establishes one stateful session per server, and at the start of that session the two sides negotiate capabilities. A server can only offer what it has declared. For example, tool invocation requires the server to declare tool capabilities.
A server can expose more than tools. It can also offer resources (context and data) and prompts (templated messages). A client can offer sampling. Keep this full list in mind, because some MCP clients support only part of it, and the exam tests that gap.
The architecture also has a design goal that matters for security questions: servers are kept narrow and isolated. The full conversation history stays with the host, each server connection is isolated, and the host controls any interaction between servers. Servers are meant to be easy to build and to combine, so a new system becomes one more focused server rather than a change to the host.
The specification pairs this with consent rules. Tools represent arbitrary code execution, and hosts must obtain explicit user consent before invoking any tool.
No. In MCP the host keeps the full conversation, and each server connection is isolated. Any interaction between servers is controlled by the host. A server receives only the context it needs.
3.Direct tool use: you define the tool, your code runs it
Direct tool use (also called function calling) is the baseline mechanism. You pass a tool with a name, a description and an input_schema. Claude decides whether to call it from the user's request and the tool's description. If it does, the response stops with stop_reason: "tool_use" and contains a tool_use block. Your code performs the operation and sends the output back in a tool_result block, and Claude uses it to answer.
This is the "API/CLI" route. What the tool does is up to your code. It can call an internal API, query a database, or run a shell command. The documentation calls these client tools, and they include tools with Anthropic-defined schemas such as bash and text_editor. Server tools such as web_search, web_fetch, code_execution and tool_search run on Anthropic's infrastructure, so you receive their results without running anything yourself.
tools = [
{
"name": "get_weather",
"description": "Get the current weather for a given location.",
"input_schema": {
"type": "object",
"properties": {
"location": {
"type": "string",
"description": "City and state, e.g. San Francisco, CA",
}
},
"required": ["location"],
},
}
]The trade-off is ownership. Direct tool use needs no server and no protocol, but you write the tool loop, the execution and the result formatting. You can skip writing the loop by hand with Tool Runner, which runs your tools and sends the results back for you. Each integration still lives inside your application, though. Another host cannot reuse it the way it could reuse an MCP server.
A fintech company wants Claude to call tools hosted on an internal Postgres query service. The service currently only exposes a local stdio-based MCP server used by developers on their laptops, but the production app needs Claude to invoke it directly from server-side Messages API calls without operating a separate MCP client process. What should the team do?
Correct answer: A — Deploy the query service as a remote MCP server reachable over HTTPS via Streamable HTTP or SSE, then reference it in the mcp_servers array.
- A. Correct. The MCP connector only supports remote servers exposed over HTTPS using Streamable HTTP or SSE transport, so moving the service to a publicly reachable endpoint and referencing it in mcp_servers is the supported path.
- B. Incorrect. The MCP connector cannot spawn local stdio servers; the server must already be publicly exposed over HTTP-based transports.
- C. Incorrect. This abandons MCP entirely and requires the team to hand-build and maintain a tool_use schema instead of reusing the existing MCP interface.
- D. Incorrect. The Files API manages document and data uploads, not MCP tool schemas or server connectivity.
Sources2
4.The MCP connector: MCP from the Messages API without writing a client
Between writing your own tools and writing your own MCP client there is a third option. The MCP connector lets a Messages API request connect directly to remote MCP servers. It has two parts. The mcp_servers array defines each connection (URL and authentication). An mcp_toolset entry in the tools array chooses which of that server's tools are enabled. You can enable all of them, allowlist specific tools or denylist unwanted ones, and one request can use several servers.
{
"type": "url",
"url": "https://example-server.modelcontextprotocol.io/sse",
"name": "example-mcp",
"authorization_token": "YOUR_TOKEN"
}| Property | Required | Constraint |
|---|---|---|
| type | Yes | Currently only "url" is supported |
| url | Yes | Must start with https:// |
| name | Yes | Must be referenced by exactly one MCPToolset in the tools array |
| authorization_token | No | OAuth authorization token if required by the MCP server |
Two limits decide whether the connector fits. First, the server must be publicly exposed over HTTP, using Streamable HTTP or SSE. A local STDIO server cannot be connected directly. Second, the connector supports only tool calls from the MCP feature set. Resources, prompts and sampling are not available through it. If you need either of those, you need an MCP client you build yourself, which the documentation points to separately.
Connecting a server does not make Claude call it on every turn. Claude calls a tool when the request matches what that tool is described as doing. General questions about the connected service are answered directly. You can adjust how readily Claude uses the tools through the system prompt.
A platform team is building an automated CI pipeline step where Claude must read repository files, run test commands, and edit code across multiple iterations until tests pass, without the team writing custom logic to parse tool_use blocks and resubmit tool results. Which integration approach best fits this need?
Correct answer: A — Use the Claude Agent SDK, which provides the agent loop, built-in tools like Read, Edit, and Bash, and manages tool execution automatically.
- A. Correct. The Agent SDK ships the agent loop and built-in tools such as Read, Edit, and Bash, so the team gets autonomous multi-step tool execution without writing the loop themselves.
- B. Incorrect. This describes the Client SDK path, which requires the team to implement and maintain the tool execution loop manually.
- C. Incorrect. Interactive CLI use requires a human present to approve steps, which defeats the goal of an unattended automated pipeline step.
- D. Incorrect. MCP exposes external tools to Claude but does not provide the local Read/Edit/Bash agent loop needed to operate directly on the pipeline's own repository checkout.
Sources4
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.The Messages API MCP connector can connect to any MCP server, including a stdio server running on the developer's machine.Why is that wrong?
The connector only reaches servers exposed publicly over HTTP, using Streamable HTTP or SSE. It cannot connect directly to a local STDIO server.
Covered in The MCP connector: MCP from the Messages API without writing a client
2.Attaching an MCP server through the connector gives Claude the server's resources and prompts as well as its tools.Why is that wrong?
Of the MCP feature set, the connector currently supports only tool calls. Resources and prompts need a different client.
Covered in The MCP connector: MCP from the Messages API without writing a client
3.An MCP server receives the whole conversation so it can use earlier context from other tools.Why is that wrong?
The full conversation history stays with the host, and each server connection is isolated.
Covered in What MCP standardises, and what it isolates
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“Clients: Connectors within the host application”
↩︎ Three ways to give Claude a capability“Hosts must obtain explicit user consent before invoking any tool”
↩︎ What MCP standardises, and what it isolates - 2.
“Claude determines when to call a tool based on the user's request and the tool's description.”
↩︎ Three ways to give Claude a capability“Client tools (including user-defined tools and tools with Anthropic-defined schemas, such as bash and text_editor) run in your application.”
↩︎ Direct tool use: you define the tool, your code runs it“Your code executes the operation and sends back a tool_result.”
↩︎ Direct tool use: you define the tool, your code runs it“Tools differ primarily by where the code executes.”
↩︎ Key concept - 3.
“Establishes one stateful session per server”
↩︎ What MCP standardises, and what it isolates“Tool invocation requires the server to declare tool capabilities”
↩︎ What MCP standardises, and what it isolates“Cross-server interactions are controlled by the host”
↩︎ What MCP standardises, and what it isolates“Full conversation history stays with the host”
↩︎ Exam trap 3 - 4.
“connect to remote MCP servers directly from the Messages API without a separate MCP client”
↩︎ The MCP connector: MCP from the Messages API without writing a client“Flexible tool configuration: Enable all tools, allowlist specific tools, or denylist unwanted tools”
↩︎ The MCP connector: MCP from the Messages API without writing a client“Claude does not call an MCP tool for general knowledge questions about a connected service.”
↩︎ The MCP connector: MCP from the Messages API without writing a client“Local STDIO servers cannot be connected directly.”
↩︎ Exam trap 1“Of the feature set of the MCP specification, only tool calls are currently supported.”
↩︎ Exam trap 2