MCP vs tool use
MCP and tool use are not alternatives at the model's end: an MCP tool still reaches Claude as an ordinary tool definition. The real choice is where the tool lives and who owns it.
Short answer
Every MCP tool arrives at the model the same way a tool you defined yourself does, as a tool definition in the request, and the tool-use loop is identical either way. So the decision is not about capability. It is about ownership and distribution: define the tool in your own request when one application uses it and you own the implementation, and put it behind an MCP server when several hosts need the same capability or another team should own its interface.
The question is usually asked as though it were a choice between two ways of giving a model capability, and that framing is what makes it hard. Mechanically there is only one way. Claude receives a list of tool definitions, decides it wants one, and your code executes it and returns the result. An MCP server does not change that. The host connects to the server, asks it what tools it has, and puts those tools into the request as definitions. From the model's side, nothing is different.
What MCP changes is everything around the model. The implementation moves out of your application and behind a protocol boundary. Discovery becomes dynamic, so the tool surface can change without redeploying the host. The same server can serve a different application tomorrow. And a trust boundary appears where there was not one before, because the thing describing the tools is no longer code you wrote.
That is the trade, and it is an ordinary engineering trade about coupling and reuse rather than a question about models. Treating it as an AI question is what produces the wrong answer.
Tools defined in the request vs Tools served over MCP, side by side
| Tools defined in the request | Tools served over MCP | |
|---|---|---|
| What the model receives | A tool definition in the request | A tool definition in the request, which the host fetched from a server first |
| Who owns the implementation | Your application | Whoever runs the server, which may be another team or a third party |
| Reuse across applications | None. Each application defines its own copy. | The point of the protocol. Any compliant host can connect to any compliant server. |
| What you have to operate | Nothing beyond your app | A server process, its transport, and its authentication |
| Discovery | Static. You wrote the list, so it changes when you deploy. | Dynamic. The host lists tools at connect time, so the surface can change underneath it. |
| Trust boundary | Inside your application | Across a process or network boundary. Descriptions and annotations come from the server. |
| Cost of a bad tool description | Poor selection in one application | Poor selection in every host that connects |
Both roads end at the same tool definition
This is the fact that resolves most confusion, so it is worth stating plainly. Whether you hand-wrote a tool or a server advertised it, the model sees a name, a description and an input schema. When it wants to use one it returns stop_reason: "tool_use", your host executes the call and replies with a tool_result carrying the matching tool_use_id, and the conversation continues.
The host runs that loop in both cases. MCP does not run it for you and does not replace it. What the protocol standardises is the step before the loop, where the host asks a server what it offers, and the step during execution, where the host forwards the call to the server rather than to a local function.
MCP buys distribution, not capability
The value of the protocol is the many-to-many property. An integration written once as a server can be used by a desktop client, a CLI, a coding tool and your own application, without any of them knowing how it works. That is a real and substantial benefit when a capability has more than one consumer, or when the team that owns a system should also own how it is exposed.
It buys nothing when there is exactly one consumer and you own both sides. In that case the server is an extra process to run, monitor, authenticate and version, sitting between your application and code that was already in it. The honest question is whether a second consumer exists or is genuinely coming, not whether the protocol is the modern approach.
The costs the protocol adds
Three are worth pricing before you commit.
- Operations: a server is a process with a lifecycle. Over stdio the host launches it as a subprocess; over Streamable HTTP it is a network service you must deploy, secure and keep available.
- Security: an HTTP server has obligations that are stated normatively in the specification, including validating the
Originheader and binding to localhost rather than all interfaces when it runs locally. Where authorization is implemented it is OAuth 2.1, with tokens bound to the intended audience and never forwarded onward. - Trust: the tool descriptions and annotations arrive from the server. Annotations such as
readOnlyHintare explicitly hints rather than guarantees, so a host that skips approval because a tool claims to be read-only has moved its safety decision to someone else's metadata.
Context cost is the same either way, and it is not free
Every tool definition available to a request sits in the context window on every request, whether you typed it or a server advertised it. Connecting three servers that expose twelve tools each puts thirty-six definitions in front of the model on every call.
That costs tokens continuously and, more importantly, makes selection harder: the more similar tools compete, the less reliably the right one is chosen. The mitigations are the same in both worlds. Expose the tools a given workflow actually needs rather than everything available, keep descriptions specific enough to separate neighbours, and consider deferred loading so a large library stays out of context until something relevant is required.
The migration path is one-way and cheap
A sensible default is to start with tools defined in your request. You get the shortest path to working software, no extra process, and the smallest possible surface. If and when a second consumer appears, promoting a tool to a server is mostly a packaging exercise, because the schema and the implementation already exist.
Going the other way is harder, since by then other hosts depend on the server's interface. So the decision is less risky than it looks in one direction and more binding than it looks in the other. Where the capability is clearly a reusable integration from the start, such as an interface onto a system another team owns, going straight to a server is right. Otherwise, earn it.
How to choose
Reach for tools defined in the request when
- One application uses the capability and you own the implementation
- The tool needs credentials or in-process state only that application holds
- You want the smallest possible tool surface in the context window
- The capability is changing quickly and redeploying is easier than versioning an interface
Reach for tools served over mcp when
- A second host needs the same capability, such as a CLI, a desktop client or another service
- Another team owns the system behind the tool and should own how it is exposed
- The tool surface needs to change without redeploying every host
- The capability is a reusable integration rather than a feature of one application
Where candidates go wrong
Trap 1: MCP is an Anthropic API feature
It is an open protocol built on JSON-RPC 2.0, with its own specification, transports and SDKs, usable by any compliant host and any compliant server. Anthropic products connect to MCP servers and the Claude API offers a way to reach them, but the protocol is not part of the API and does not depend on it. The distractors here treat MCP as a parameter you set or a mode you enable. Recognising that it is a separate specification, with a versioned revision history of its own, is what makes the rest of the domain coherent: it explains why the primitives, the transports and the security requirements are defined where they are, and why they change on their own schedule.
Trap 2: connecting a server gives the model capability for free
Every tool a server exposes is a tool definition occupying context on every request, and every request pays for it whether or not the tool is used. Connect enough servers and you have a large, permanently resident catalogue that makes correct selection harder rather than easier. The symptom in production is a model reaching for a plausible neighbour instead of the right tool, which reads like a model problem and is a surface problem. Options that propose connecting more servers to improve capability, without mentioning what that costs, are usually the wrong answer.
Trap 3: MCP replaces the tool-use loop
It does not. The host still receives stop_reason: "tool_use", still executes, and still returns tool_result blocks with matching identifiers, including on failure. The protocol standardises how the host reaches the implementation, not how the conversation with the model is conducted.
This matters practically because error handling stays your responsibility. MCP makes its own distinction, between protocol errors such as an unknown tool, returned as JSON-RPC errors, and execution failures returned inside the result with an error flag so the model can see and correct them. Either way, something has to turn that into a tool_result the model can act on.
Trap 4: the server's annotations tell me what is safe to run
Tool annotations look like a permission model and are not one. The specification states that every property in the annotations object is a hint, and that clients must treat annotations as untrusted unless they come from a server the host already trusts. A careless or hostile server can label a destructive tool as read-only. Approval policy belongs to the host, which is the component that knows what the user consented to. Any option that uses metadata supplied by the tool provider as the basis for skipping human approval is wrong, and it is wrong in the same way whether the metadata came over MCP or was written into a local tool definition by a well-meaning colleague.
How the exam tests it
Tools and MCPs is 10.6% of the CCDV-F blueprint, roughly 6 of the 53 scored questions, split into Tool Implementation (4.4%), Agentic Customization (4.1%) and MCP Server Development (2.1%). Note the shape of that split: two thirds of the domain is about tools and capability surfaces, and only a fifth is about the protocol itself, which is a fair guide to where preparation time belongs.
Common questions
Is MCP a replacement for tool use?
No. An MCP tool is delivered to the model as an ordinary tool definition, and the tool-use loop is unchanged. MCP standardises how a host discovers and reaches an implementation, which is a distribution and ownership concern rather than a model-facing one.
When should I build an MCP server instead of defining tools directly?
When more than one host needs the capability, or when another team owns the system behind it and should own its interface, or when the tool surface must be able to change without redeploying every consumer. For a capability used by exactly one application that you also own, defining tools in the request is simpler and cheaper.
Does connecting an MCP server cost anything at request time?
Yes. Every tool the server exposes becomes a tool definition in the context window on every request, so it costs tokens continuously and adds competition for the model's selection. Expose the tools the workflow needs rather than everything the server offers.
Who runs the tool-use loop when MCP is involved?
The host application. It receives the model's tool-use request, forwards the call to the server, and returns the result to the model as a tool result. The protocol sits between the host and the server, not between the host and the model.
Can I trust a tool's annotations to decide whether it needs approval?
No. The specification is explicit that annotations are hints, not guarantees, and that clients should treat them as untrusted unless the server is trusted. Approval belongs to the host, which knows what the user actually agreed to.
What does an MCP server owe me on the security side?
If it listens over HTTP it should validate the Origin header to prevent DNS rebinding, bind to localhost rather than all interfaces when running locally, and authenticate connections. Where authorization is implemented it is OAuth 2.1, with tokens audience-bound to the server and never passed through to another service.
Practise this
Tools and MCPs is 10.6% of the CCDV-F blueprint, and the bank is weighted to match. Every option carries a written explanation, not just the correct one, so a distinction like this one is explained where you get it wrong.
See CCDV-FOther CCDV-F distinctions
Not affiliated with or endorsed by Anthropic. Domain names and weightings are taken from the published exam guide; always check the official guide before booking.