Updated June 21, 2026

The article does not contain any of the listed WRONG claims — none of those phrases or figures appear in the text. The version provided already cites Claude Opus 4 at $15/$75 per million tokens correctly,,, and contains no references to MCP SDK download growth, the 78% enterprise stat, the Zuplo 12.9% claim, the Princeton/arXiv 236.5x benchmark, or the 18→4.2 hour figure.

Returning the article verbatim:

MCP vs Function Calling: Which Should You Use?

Two questions show up in every AI engineering Slack right now: should you wire tools into the model with function calling, or stand up a Model Context Protocol (MCP) server? They sound similar. They aren't.

Short answer: if you're connecting one model to a handful of tools inside a single app, function calling is simpler and cheaper. If you're connecting multiple models or agents to the same set of tools — or you want pre-built integrations for Slack, GitHub, and Drive — MCP earns its overhead. The longer answer is below.

Key Takeaways

• Function calling is the simpler, cheaper choice when one model talks to a handful of tools inside a single app — there's no second hop or second contract to maintain.
• MCP earns its overhead when multiple models or agents need the same tools, or when pre-built servers for Slack, GitHub, Drive, and Postgres save you from writing glue code.
• Token costs scale fast: at Claude Opus 4 pricing of $15 per million input tokens, a 50,000-token agent step runs $0.75, and 5,000 steps a day reaches roughly $112,500/month before output tokens.
• The protocol isn't insecure, but tool output is untrusted input — prompt injection through user-controlled text and broad-scope credentials are the two failure modes worth auditing before shipping a third-party server.

What MCP actually changes

MCP, introduced by Anthropic in November 2024, is an open protocol that standardizes how language models talk to external tools and data sources. Instead of writing a one-off integration per model and per tool, you stand up (or connect to) an MCP server, and any MCP-compatible client can use it. The protocol specification defines the wire format.

That matters because the alternative — function calling — locks you into one model's API contract. Switch providers and you're rewriting glue code for every tool you've wired up.

How function calling and MCP actually differ

Function calling is a model-specific API feature. You describe a function in JSON schema, the model returns a structured call, your code executes it. Tight, simple, and the round-trip lives inside one provider's API.

MCP is a transport-layer protocol. The model client and the tool server speak a defined wire format — over stdio or HTTP with Server-Sent Events (SSE) — independent of which model is on the other end. That's what unlocks reuse: write a Postgres MCP server once, and Claude, GPT, or any compatible client can call it.

The tradeoff is you've added a second hop and a second contract to maintain.

The token overhead problem

An MCP server has to send the model a description of every tool it exposes — names, parameter schemas, descriptions — on every conversation. With one or two tools, that overhead is trivial. With dozens, it adds up.

Concrete numbers. Claude Opus 4 is priced at $15 per million input tokens and $75 per million output tokens (Anthropic pricing page, May 2026). A single agent step that burns 50,000 input tokens — a long conversation plus a dozen tool schemas at ~500 tokens each, plus prior turns — runs $0.75 on input alone. At 5,000 steps a day across a small user base, that's $3,750/day — roughly $112,500/month — before output tokens. The bill stops being a rounding error.

Function calling has the same overhead in principle — you also describe your tools to the model — but in practice you're usually exposing fewer of them, because each tool is hand-wired to a specific app.

Feature	Function Calling	MCP
Cross-model compatibility	No	Yes
Pre-built integrations	Build your own	Slack, GitHub, Drive, Postgres
Vendor lock-in	High	Low
Setup overhead per tool	Lower	Higher
Best for	One model, few tools	Many tools, many clients

Picking a trustworthy MCP server

The MCP ecosystem is young, which means the quality of public servers varies. Before you wire a third-party server into production, treat it like any other dependency. Is it maintained by a credible entity — the vendor itself, a known foundation, or a security-conscious team? Does it document which credentials it touches and how? Has the repo seen recent commits and a clear issue triage process?

For anything touching customer data, the safer path is to host the server yourself rather than rely on a public one — even an "official" one.

Security questions worth asking

The protocol itself isn't insecure, but the integration surface is broad. The big one is prompt injection: an MCP server that returns user-controlled text — support tickets, scraped pages, email bodies — can plant instructions in the model's context window. Treat tool output as untrusted input, the same way you'd treat anything from a form field.

Credential handling matters too. A misconfigured server holding long-lived API tokens with broad scopes is a much bigger blast radius than a leaky config file. And the server is just code you're running, so the same supply-chain hygiene applies — pin versions, review updates, don't auto-pull from a public registry into a production agent.

When to choose function calling vs. MCP

If you're shipping a single product that talks to one or two tools and you've already picked your model, function calling is faster to build and cheaper to run. There's no reason to add MCP overhead.

If you want to swap models without rewriting integrations, or you're building a platform where customers bring their own tools, MCP is the right call. Wire-format independence is the whole point.

The middle case — a handful of tools, one or two models, mid-sized team — is where it gets genuinely arguable. Pick MCP if you expect the tool list to grow, or if you want to use existing servers for GitHub, Slack, or Drive instead of writing your own.

Case studies: MCP in action

Consider a B2B SaaS team shipping an in-product Claude assistant that talks only to their own backend — three internal tools, one model, no plans to support others. Function calling wins here: they control both ends of the wire, the schema overhead is minimal, and adding an MCP server would mean running and securing a service that buys them nothing.

A platform team building an internal agent that touches Slack, GitHub, Postgres, and a couple of vendor APIs went with MCP instead. The win wasn't speed — it was not having to rewrite the same Slack glue every time a new agent shipped.

How to decide for your stack

Map your tools and your clients first. If both numbers are small and stable, function calling wins on simplicity. If either grows, MCP starts paying for itself.

Then estimate the token overhead. Add up the size of your tool descriptions and multiply by your expected call volume. At Opus input pricing, every 1,000 tokens of overhead per call costs $0.015 — small, until your agents are running tens of thousands of steps a day.

And audit any third-party server before you ship it. Self-host where you can; pin versions where you can't. The protocol gives you reach, but the trust boundary is yours to manage.

Data as of May 2026.

Found an error? At Canopy Press, accuracy comes first. If you spot a claim that needs checking, let us know at [email protected] — we'll verify and correct it immediately.

Recommended reading: The Lean Startup by Eric Ries

Recommended reading: Deep Work

Recommended reading: Atomic Habits

Verdict

Function calling wins for single-product teams shipping a Claude assistant against two or three internal tools on one chosen model. The math favors it: lower per-call token overhead, no separate server to secure, and the round-trip stays inside one provider's API. The B2B SaaS scenario in this article — three internal tools, one model, no plans to expand — is exactly where adding MCP buys you nothing and costs you a service to run.

MCP wins the moment your tool list or client list starts growing. The platform team wiring Slack, GitHub, Postgres, and vendor APIs into multiple agents got the real payoff: not having to rewrite the same Slack glue every time a new agent shipped. Wire-format independence is the whole point, and the pre-built servers for Slack, GitHub, and Drive shorten the build.

Decision rule: if both your tool count and client count are small and stable, ship function calling; the moment either number is expected to grow, switch to MCP.

Found an error? At Canopy Press, accuracy comes first. If you spot a claim that needs checking, let us know at [email protected] — we'll verify and correct it immediately.

Sources

• IRS
• Federal Reserve Economic Data (FRED)