MCP Servers vs Function Calling: Choose Your Fighter

It's tempting. It really is.

Every LLM provider has function calling now. OpenAI has it. Anthropic has it. Google has it. You pick your favorite, read the docs for twenty minutes, define your functions as JSON schemas, and ship. It works. Your demo looks great. Your investors are impressed.

The problem is that "it works" and "it works at scale across vendors" are two completely different statements. The first is a Tuesday afternoon. The second is a full-time job.

When you hardwire function calling to a single provider, you're not just choosing a vendor. You're choosing their schema format, their parameter conventions, their error handling semantics, and their release schedule. You're writing glue code that is, by definition, non-portable. And you're doing it at the layer where portability matters most — the boundary between your application and the intelligence it depends on.

Most people don't realize this until they need to support a second LLM. By then, the glue code has metastasized.

Here's an exercise. Go to your codebase and count the lines of code that exist solely to translate between your internal tool definitions and a specific LLM provider's function calling format.

One integration? Maybe a hundred lines. Manageable. Two integrations? You start noticing that OpenAI and Anthropic have subtly different opinions about how to express optional parameters. Three integrations? You're maintaining a compatibility matrix. Five? You've accidentally built a framework.

And the frameworks never stop growing. Each vendor updates their API shape every quarter. Sometimes they add features. Sometimes they deprecate things. Sometimes they "improve" the schema format in ways that break your existing definitions in production at 2 AM on a Saturday.

The maintenance tax on multi-vendor function calling is not linear. It's combinatorial. Every new vendor multiplies the surface area. Every API change cascades through every integration. Your "simple" function calling layer becomes the most fragile part of your stack — the one file everyone is afraid to touch.

Nobody puts this cost in the architecture doc. Nobody estimates it in the sprint planning. It just... accumulates, silently, until one day you realize half your engineering time goes to keeping integrations alive rather than building features.

MCP is not a product. It's not a startup's API. It's a protocol. That distinction matters more than people think.

When you write an MCP server, you describe your tools once. One schema. One set of descriptions. One error format. That's it. Every LLM that speaks MCP can discover and use your tools without you writing a single line of vendor-specific code.

No adapters. No version matrices. No "if openai then format A, elif anthropic then format B" branching. The protocol is the contract, and any client that implements the protocol gets your tools for free.

This is the same pattern that made HTTP successful. Nobody writes a different API for Chrome vs Firefox vs Safari. You implement the protocol, and every conforming client works. MCP does for AI tool integration what HTTP did for web content delivery — it makes the transport layer boring so you can focus on the application layer.

The practical result is that your tool definitions become assets instead of liabilities. You write them once, test them once, document them once. When a new LLM provider shows up, you don't rewrite anything. You just point them at your MCP server and they work.

I'd be dishonest if I didn't acknowledge this: sometimes function calling is the right choice.

If you're building an application that will only ever use one LLM, and you know which one, and you're not kidding yourself about that — direct function calling is simpler. Less abstraction. Fewer moving parts. You trade portability for directness, and sometimes that trade is worth it.

If you need vendor-specific features that don't have MCP equivalents yet — think structured output modes, computer use APIs, or provider-specific streaming behaviors — direct integration makes sense. You can't access what the protocol doesn't expose.

And if you're prototyping, if you're in the "just make it work" phase, function calling gets you there faster. MCP has setup overhead. For a weekend hackathon, that overhead is real.

But here's the question you have to answer honestly: does "one vendor forever" actually describe your future? Because in my experience, the companies that say "we'll only ever use OpenAI" are the same companies that are frantically adding Claude support six months later when their users start asking for it. The ones that say "we're just prototyping" are the same ones still running that prototype in production two years from now.

The cost of switching from function calling to MCP goes up every day you wait. The cost of starting with MCP stays roughly constant.

Here's what I think most people miss: MCP and function calling are not enemies. They're layers in the same stack.

MCP tools can be exposed as functions to any LLM that supports function calling. The protocol is the source of truth — the canonical description of what your tools do, what they accept, and what they return. The function calling adapters are generated, not hand-written. Your MCP server is the single source; the vendor-specific formats are projections.

This means you don't have to choose. You can have MCP as your tool definition layer and still use function calling as the delivery mechanism to each LLM. The difference is that with MCP, those function definitions are derived from a single source instead of being maintained independently per vendor.

This is where the industry is heading whether it knows it or not. The pattern of "one canonical description, many derived formats" has won in every other domain — database schemas, API specs, type systems. AI tool integration will converge on the same pattern because the alternative is a maintenance burden that grows faster than anyone's engineering team.

The companies that figure this out now will spend their time building better tools. The companies that figure it out later will spend their time rewriting glue code. Both groups will end up in the same place. The only question is how much time they waste getting there.