MCP vs API: When Direct Calls Win and When MCP Pays Off

MCP vs API comes down to who controls the agent. If your code runs the agent loop and the tools serve one app, a direct API call or function calling with your own tool schema is cheaper, faster, and easier to secure. MCP pays off when the same tools must work across several clients you do not build, such as Claude, ChatGPT, VS Code, or Cursor.

MCP does not replace your APIs. It wraps them. Below: when each option wins, the cost, latency, security, and upkeep differences under the 2026-07-28 spec, and a decision table. New to the protocol? Start with what MCP is.

MCP vs API: what are you actually choosing between?

There are three options, not two.

A direct API call in your code. No model decides anything. Your code calls the API at a fixed step and puts the result in the prompt.

Function calling with your own tool schema. You send tool definitions with each model request. Anthropic calls the schema field input_schema, as in its tool search docs. OpenAI calls it parameters in its function calling guide. The model returns a tool name and arguments, and your code runs the call.

MCP. A server publishes tools through tools/list. A client fetches them, hands them to the model as ordinary tool definitions, and forwards the model’s choice to the server through tools/call. So MCP rides on function calling. What changes is who writes the schemas and who runs the code, as Nango’s comparison puts it.

Under the hood, most MCP servers are API clients. A study of 116 official MCP servers excluded two that generate tools dynamically and classified the other 114. Of those, 101 (88.6%) are fully or partially REST-backed. Of the 87 fully REST-backed servers, 80 (92%) contain only tools that are bare API calls. Across the 42 servers the authors could pair with a public OpenAPI spec, median coverage was 19% of the API’s operations.

One correction to many MCP vs API pages: they still describe MCP as stateful. The 2026-07-28 revision removed the initialize handshake and the Mcp-Session-Id header. Servers that need state across calls mint handles and receive them back as ordinary tool arguments. The full revision history is in the MCP roadmap post.

When does a direct API call or function calling beat MCP?

Four situations favor keeping the integration in your own code.

The step is deterministic. If every support case needs the customer record, fetch it in code before the model runs. A model-chosen tool call costs an inference turn, and the model can skip it or pass the wrong arguments. My rule: if a step runs on every case, it is code, not a tool.

One app owns the loop. If the tools serve only your agent, an MCP server adds a process, a transport, and a protocol version to maintain, and buys reuse you will not use. Switching model vendors changes only the schema envelope (input_schema versus parameters). Your API client, auth, and retry code stay put, and most frameworks ship the adapter (see choosing an agent framework).

Your customers authorize their own accounts inside your product. Nango, an integrations vendor, notes that MCP’s OAuth flow authorizes your agent to the MCP server, while auth to the underlying API is “whatever the server operator built,” and says public servers rarely handle per-user tokens across tenants. It also reports that fewer than 10 of “several hundred teams” in its fall 2025 survey kept MCP in production, with no published method.

You need a small, sharp toolset. Anthropic’s tool search docs say Claude’s ability to pick the right tool degrades past 30 to 50 available tools. OpenAI suggests fewer than 20 functions per turn and calls it “a soft suggestion.” Shaping tools is covered in AI agent tool design.

When does MCP’s reuse across clients pay off?

MCP earns its keep when the tool has consumers you do not write.

Clients you do not control. The MCP introduction lists Claude, ChatGPT, VS Code, and Cursor among its clients. Your own function-calling loop does not run inside those apps. Some hosts have their own extension APIs. A VS Code extension can register tools with vscode.lm.registerTool, and VS Code’s docs favor an extension tool for deep VS Code integration and an MCP server when you do not need VS Code APIs. Those APIs are host-specific. MCP is the portable option: one server for every host that supports it.

Many agents on different stacks. Say a platform team owns the ticketing system and five product teams build agents in three frameworks. One MCP server, owned by the people who own the API, beats five copies of the same tool code.

Hosted connectors. Anthropic’s MCP connector lets the Messages API connect to servers “without a separate MCP client.” It is in beta, supports only tool calls, needs a server “publicly exposed through HTTP,” and is not eligible for zero data retention. OpenAI’s Responses API takes a tool of type: "mcp", per its MCP guide. It asks for approval before each call by default. It is compatible with zero data retention on OpenAI’s side, but data sent to the server falls under the server’s own retention and residency policies, and OpenAI says checking that the server meets your requirements is your responsibility.

The “N times M” argument (every model times every tool) only holds when the consumers are separate products. Five internal agents importing one shared API client library are already “N plus M.” MCP adds reuse across processes, languages, and vendors.

Decision rule (mine): build an MCP server when a tool must reach two or more hosts you do not build, or one host with no extension API that fits, or its third internal consumer on a different stack.

Cost: tool definitions are the hidden line item

Every tool the model can see is billed as input tokens on every call, per OpenAI’s guide. Anthropic’s pricing page counts names, descriptions, and schemas, and adds a 286-token tool-use system prompt on Sonnet 5.5.

Generic servers are heavy. Anthropic’s advanced tool use post gives a five-server example: GitHub (35 tools, about 26K tokens), Slack (11 tools, about 21K), Sentry, Grafana, and Splunk. That is 58 tools and about 55K tokens “before the conversation even starts.” And 58 tools is past the 30 to 50 range where selection accuracy drops.

Hypothetical worked example. A support agent handles 20,000 tickets a month at 8 model calls each, so 160,000 calls. It runs on Claude Sonnet 5.5 at $2 per million input tokens, $2.50 per million for 5-minute cache writes, and $0.10 per million for cache hits. Option one connects those five generic servers. Option two uses six custom tools at an assumed 1,200 tokens of definitions. The cached column assumes one cache write per ticket, then 7 cache hits.

The ratio holds at any volume: 55,000 / 1,200 is about 46 times. At 2,000 tickets a month, the uncached gap is $1,760 versus $38.40.

The cost comes from the catalog, not the protocol. Your own MCP server with the same six tools costs what function calling costs. For generic servers, use allowlists (allowed_tools on OpenAI, toolset configs on Anthropic) or tool search. More levers are in reducing agent token costs.

Latency: where MCP adds time

MCP adds time in four places.

Bigger prompts. Without a cache hit, a 55K-token tool catalog is processed on every call before the model answers. Anthropic’s prompt caching docs say a cached prefix reduces processing time, and tools sit at the front of that prefix. The definitions still fill the context window, though, and changing any tool definition invalidates the whole cache. Tool search shrinks the catalog but, per Anthropic, “adds a search step before tool invocation.”

The extra hop and the server you picked. An MCP call goes to the server first, then to the API. Server choice matters more than the protocol. One independent TM Dev Lab benchmark from February 2026, before the stateless revision, ran I/O-bound tools against Redis and an HTTP API at 50 concurrent users. Average latency ranged from 4.04 ms (Quarkus) and 6.87 ms (Go) to 123.50 ms (Node.js) and 251.62 ms (Python). The author attributes Python’s throughput ceiling to “FastMCP session overhead.” One test on one setup, so measure your own.

The handshake, now gone. Legacy clients had to run initialize before their first call. Under 2026-07-28, a modern client can call any method directly.

Approvals. OpenAI’s remote MCP tool requests approval for each call by default. The response returns an mcp_approval_request, and your app must send a new request with an mcp_approval_response, which adds a round trip to the model API. If a person reviews it, add their time too. Set require_approval to never for tools you trust.

Decision rule (mine): if a tool step has a p95 budget under about 50 ms, keep it in process. More on where agent time goes in AI agent latency.

Security: who owns the code that touches your data?

With function calling, the definitions, code, and credentials are yours. MCP adds three surfaces.

Untrusted tool descriptions. Invariant Labs described tool poisoning in April 2025: malicious instructions in tool descriptions, “invisible to users but visible to AI models.” It also described the rug pull, where “a malicious server can change the tool description after the client has already approved it.” Its fix: pin server and tool versions.

Data reach. OpenAI’s MCP guide warns that “a malicious server can exfiltrate sensitive data from anything that enters the model’s context.”

Auth and local execution. The MCP security best practices say servers “MUST NOT accept any tokens that were not explicitly issued for the MCP server.” Proxy servers that use one static client ID with a third-party API must collect per-client consent, or they become confused deputies. Local servers can run with the client’s privileges, so one-click setup must show the exact command and get explicit approval.

Decision rule: owning the server removes third-party code risk, not MCP’s own risks. A first-party server still needs token audience checks, per-client consent if it proxies a third-party API, handles that cannot be hijacked, and a locked-down transport. A third-party server also gets a pinned version, an allowlist of tools, a code review, and a gateway in front of it. The threat model in depth is in the MCP security guide.

The operational burden of running MCP servers

A function-calling tool ships inside your app. An MCP server is a separate service with its own protocol contract. Here is what you take on under the 2026-07-28 spec.

Decision rule: if nobody will own the server’s upgrades and security reviews for at least the next twelve months, do not ship one.

MCP vs API decision table

Row 1 carries the most weight: if two or more hosts you do not build need the tool, build an MCP server. If only one host needs it, its own extension API (such as a VS Code extension tool) can be the better fit. Otherwise, default to function calling, and move to MCP when rows 2 and 7 both point that way.

Worked example (hypothetical). A 300-person logistics company has a shipment-tracking REST API and three needs.

1. A customer chat agent in its web app. Rows 1, 3, and 4 point to function calling: five custom tools, the customer’s token from the app session, and a direct API call that loads the shipment before the model runs.
2. Operations staff querying shipments from Claude and ChatGPT. Row 1 decides, with two hosts and no shared extension API: one first-party MCP server with four read-only tools, OAuth through the company identity provider, behind a gateway.
3. A nightly reconciliation job. No model is involved, so it is plain API calls.

All three import the same internal API client, so the business logic exists once.

Bottom Line

MCP vs API is a question of who runs the agent, not which is better.

Own the loop and the toolset? Use direct calls and function calling. Need the tool across several AI apps you do not build? Build one first-party MCP server and give it an owner.

MCP’s cost is mostly the tool catalog, and its risk mostly third-party code. Curate one, pin the other.

Next step: score your top three integrations against the eight rows above.

FAQ

Does OpenAI charge a fee per MCP tool call?

OpenAI charges no separate fee. Its MCP guide says you pay for the tokens used to import tool definitions and make calls, and “no additional fees apply per tool call.” That covers OpenAI only. The guide also says all MCP servers are third-party services under their own terms, so check the server provider’s pricing.

Can I use MCP from the Claude or OpenAI API without writing an MCP client?

Yes. Anthropic’s connector uses the mcp-client-2025-11-20 beta header; for local servers, prompts, or resources, use its SDK helpers. OpenAI’s Responses API fetches the tool list once into an mcp_list_tools item and does not refetch each turn while that item stays in context.

Is MCP stateful?

Not since 2026-07-28: no handshake and no session ID. One long-lived piece remains. A client can open a subscriptions/listen stream for change notifications it opted into, such as tool list changes.

Can I generate an MCP server from my existing API?

Yes, with review. The same study tested automated generation from API specifications. Across 2,190 sampled tool invocations, 1,666 (76%) succeeded at baseline, and automated repair raised that to 2,063 (94.2%). A generated server mirrors your endpoints, so curate it down to the tools agents need.

How many tools before I need tool search?

Anthropic recommends it at 10 or more tools, or more than 10K tokens of definitions. A request can carry up to 10,000 deferred tools. Keep your 3 to 5 most-used tools loaded so the model can call them without a search.

Three Ways to Work With TMA

Need an agent built? We deploy production AI agents in your infrastructure. Working pilot. Real data. Measurable ROI. → Schedule Demo

Want to co-build a product? We’re not a dev agency. We’re co-builders. Shared cost. Shared upside. → Partner with Us

Want to join the Guild? Ship pilots, earn bounties, share profit. Community + equity + path to exit. → Become an AI Architect