MCP vs provider function calling
This is the comparison most teams should actually be making, and the one that gets skipped because neither side is a product with a price. Function calling defines the shape of a tool definition and hands you everything else. MCP defines an out-of-process protocol so that somebody else can write the tool. The axis is a single question about your org chart: are the tool author and the model operator the same people? If they are, the boundary MCP sells you does not exist yet.
Pick provider function calling if you write the tools, run the model, use one provider, and count your tools in the tens. It is a JSON Schema, a tool_use block and a tool_result, with a published fixed cost: 286 tokens of tool-use system prompt on Claude Opus 5 for tool_choice auto or none, and 406 for any or tool. Stay on MCP if the tool author and the model operator are different people, or if one server has to serve clients you do not control. The two also compose, so this is not a one-way door.
Side by side
MCP vs provider function calling at a glance
| MCP | Provider function calling | |
|---|---|---|
| Where the tool lives | Another process, or another company's server | Your process, in your codebase |
| Scope of a definition | Advertised by the server and cached by the client, with ttlMs and cacheScope required on list results | Request-scoped: declared in the tools parameter of each API request |
| Portability | ✓ one server, many clients, any vendor that speaks the revision | ✗ none. OpenAI and Anthropic shapes differ, and the definition travels no further than your own code |
| Token overhead | Clients load all definitions upfront; Anthropic's own post describes hundreds of thousands of tokens before a request is read, and cut one case from 150,000 to 2,000 with code execution | Published per model: 286 tokens for tool_choice auto or none, 406 for any or tool on Claude Opus 5, plus only the schemas you choose to send |
| Transport and hosting | A stdio subprocess or a Streamable HTTP endpoint you deploy and operate | ✓ none. It is a field in an API request |
| Authorization | Optional OAuth 2.1 resource-server flow over HTTP, token passthrough forbidden; credentials from the environment over stdio | Whatever your own service already uses. No new surface |
| Discovery | ✓ server/discover, mandatory for servers since 2026-07-28 | ✗ none. You hard-code the list or build your own registry |
| Change notification | subscriptions/listen for tool, prompt and resource list changes | You redeploy |
| Versioning | Date-based revisions declared per request, UnsupportedProtocolVersionError with a supported list, minimum twelve-month deprecation window. Roots, Sampling and Logging deprecated in 2026-07-28 | No spec version at all. Dated API headers and dated tool type strings, such as anthropic-version: 2023-06-01 and web_search_20260209 |
| Relationship to the other | Anthropic ships an MCP connector so the Messages API can reach remote MCP servers without a separate MCP client | OpenAI's function-calling guide lists the functionality of an MCP server among its built-in tools |
| Custodian and licence | MCP a Series of LF Projects, LLC. ✓ Apache-2.0 | ✗ OpenAI and Anthropic proprietary APIs, no published licence or spec |
| Price | No price: it is a spec, and you pay in tokens and hosting | No protocol fee; the tools parameter is billed as input tokens |
| Best for | Tools written by someone other than the model operator | One application, one provider, tools you own |
Sources: Anthropic tool use · OpenAI function calling · Anthropic on code execution with MCP · MCP 2026-07-28 changelog. Compiled August 2026.
Where function calling wins
The boundary you are paying for may not exist
MCP decouples who wrote the tool from who runs the model. That is worth a protocol when those are different companies. Inside one team it means a server to deploy, a version to negotiate on every request, an authorization model to get right and a token budget for definitions, in exchange for an interface only your own code will ever call. Function calling collapses all of it into a function and a JSON Schema in the tools parameter of the request you were already making.
The token arithmetic is public, and it favours the simple path
Anthropic publishes the fixed overhead of tool use per model, which is unusual and useful: on Claude Opus 5 the tool-use system prompt costs 286 tokens with tool_choice set to auto or none, and 406 tokens with any or tool. Beyond that you send only the schemas you decided to send. The MCP path starts from the opposite default, and Anthropic describes it plainly in its 2025-11-04 engineering post: clients load all tool definitions upfront into context, models process hundreds of thousands of tokens before reading a request, and every intermediate result passes back through the model. The worked example in that post cuts 150,000 tokens to 2,000, a 98.7% saving, by having the model write code against the servers instead of calling tools directly.
Nothing to deploy, nothing to trust
An in-process tool has no local binary for a user to approve, no consent cookie, no proxy holding third-party credentials. Every risk class in MCP's security guidance that follows from being out-of-process goes with it: the confused deputy against a proxy, token passthrough, state-handle hijacking, SSRF from a malicious server pointing discovery at a link-local address, and the local-server trust problem where a client executes an unknown binary with the user's privileges. None of that means MCP is unsafe; it means the protocol buys you a boundary and the boundary has a bill.
Neither vendor is fighting MCP
This is not a bet against MCP, which matters if you are choosing a direction rather than a weekend. Both providers absorbed it: Anthropic ships an MCP connector that reaches remote MCP servers from the Messages API without a separate client, and OpenAI's function-calling guide lists MCP server functionality among its built-in tools. You can start in-process and add a server later at the point where the boundary becomes real.
Where MCP still wins
Everything above assumes you own both ends. The moment you do not, function calling has no answer at all. There is no way to consume a third party's tools without writing and maintaining that integration yourself, no way to publish your tools for a client you do not ship, and no discovery, no change notification and no cross-vendor definition. One MCP server serves every client that speaks the revision; the in-process route needs one implementation per client and per language.
The token criticism also deserves an honest expiry date. It is a statement about 2025 defaults that both layers are actively revising: MCP's 2026-07-28 revision requires ttlMs and cacheScope on list results and asks servers for deterministic tool ordering to improve prompt-cache hits, while Anthropic ships a tool search tool for working with thousands of tools by discovering and loading them on demand. If your tool count is large, the fix is on-demand loading or code execution, not a change of protocol.
Replacing an MCP server with in-process tools
The path that works:
1. Sort by authorship. Servers you wrote can become functions. Servers somebody else wrote cannot, and that split usually decides the whole question in an afternoon.
2. Make the swap mechanical. Each tool becomes a function plus a JSON Schema in the tools parameter; the JSON-RPC hop becomes an ordinary call, and the tool_use to tool_result loop replaces the client-server round trip.
3. Measure the prompt before and after. The point of the exercise is usually tokens, so count them. If they do not drop, the problem was the number of tools, not the protocol.
4. What does not move. Resources, prompts and elicitation have no function-calling equivalent, nor does list-change notification. Anything already deprecated in MCP stays out of the picture: Roots becomes tool parameters, Sampling becomes a direct provider call, and Logging becomes stderr or OpenTelemetry.
Common questions
FAQ: MCP vs provider function calling
Is function calling cheaper than MCP in tokens?
Usually, for small tool counts, and the numbers are published rather than guessed. Anthropic gives the fixed tool-use system-prompt overhead per model: 286 tokens on Claude Opus 5 for tool_choice auto or none, and 406 for any or tool, plus whichever schemas you decide to send. MCP clients start from the opposite default: Anthropic's engineering post of 2025-11-04 says they load all tool definitions upfront and describes models processing hundreds of thousands of tokens before reading a request, with one measured case at 150,000 tokens. At large tool counts the fix is on-demand loading or code execution rather than a change of protocol.
Can I use MCP and function calling at the same time?
Yes, and both vendors built for it. Anthropic ships an MCP connector that reaches remote MCP servers from the Messages API without a separate MCP client, and OpenAI's function-calling guide lists the functionality of an MCP server among its built-in tools. In practice that means in-process functions for the tools you own and MCP for the servers somebody else wrote, in one agent. Starting in-process is not a dead end: you can add a server later, at the point where the tool author and the model operator stop being the same team.
Does a function-calling tool definition work across model providers?
No. Both OpenAI and Anthropic standardize the shape of a tool definition in JSON Schema and the turn-taking around it, but the shapes differ and neither publishes a spec version, only dated API headers and dated tool type strings. Definitions are also request-scoped: they are declared in the tools parameter of each API request, so nothing is registered anywhere. Portability across providers is what in-process frameworks abstract, LangChain being the MIT-licensed example, and portability across clients is what MCP is for.