MCP and tools
Claude tool use vs MCP: when each is the right contract
Tool use on the Messages API and MCP servers are not the same design. Here is how we choose which contract Claude should use for a given job.
June 29, 2026/3 min read/Claude Certified Engineers
Claude tool use is the model selecting a function and filling arguments. Model Context Protocol is a way to host those functions as a server with a stable contract. Teams confuse the two and either over-build a protocol they do not need, or under-build a mega-tool they cannot review.
Both can be production. The schema discipline does not change.
Choose on reuse and review, not on fashion
| Situation | Prefer | Why |
|---|---|---|
| One product, one repo, one agent | In-process tool use | Less moving parts, same eval story |
| Several apps need the same CRM hands | MCP server | One review, many clients |
| Claude Code plus a product agent share tools | MCP | The contract lives outside either UI |
| InfoSec wants a process to threat-model | MCP | A box on the diagram beats "it's in the prompt" |
| Weekend prototype | Either, keep the surface tiny | Do not invent 40 tools |
The failure is the same on both
A freeform http_request tool is dangerous whether it is registered on the API or served over MCP. A constrained get_account is reviewable on both.
If you already have a catch-all, the next step is not "move it to MCP." The next step is to split verbs and run a security review. We do that split on MCP and Tool Integration whether the transport is MCP, the Anthropic API, Bedrock, or Vertex.
What MCP buys you that in-process tools do not
A process boundary. Auth in one place. Logs in one place. The same permission matrix for Claude in the product, Claude Code in the repo, and a desktop client if you add one later. InfoSec can threat-model a server. They cannot threat-model "it's in the prompt" without pretending.
What MCP does not buy you: better schemas, cheaper tokens, or a pass on eval. A 40-tool MCP catalog with overlapping verbs is worse than eight in-process tools with tests.
A migration that is not a rewrite
If the agent already works with tool use in one service, keep it. Extract an MCP server when a second consumer appears, or when the security review cannot land without a box on the diagram. Copy the same JSON Schema. Do not invent a parallel surface.
For CRM and ERP, we usually land MCP because several teams will want the same hands and because Salesforce and SAP writes need a review queue sitting next to the server, not inside a product-only codepath. For a single copilot in one repo, in-process is faster to ship in six weeks and easier to eval. Pick the contract for reuse and review. Fashion is how you get both, badly.
Questions
- What is the difference between Claude tool use and MCP?
- Tool use is the model calling named functions with JSON arguments over the Messages API. MCP is a protocol for exposing those functions as a server that many clients can attach, with a shared contract.
- Do we need MCP to ship a production agent?
- No. A single product with in-process tools is a valid production design. You need MCP when the same tools must be reused across Claude, Claude Code, desktop, or multiple internal apps, or when InfoSec wants a standalone server to review.
- Can we wrap our entire REST API as one MCP tool?
- You can. You should not. That is a remote shell. Named verbs still apply.