MCP vs Function Calling: What's the Real Difference?

If you’ve spent any time around AI agents, you’ve probably bumped into two terms that sound like rivals: function calling and MCP (the Model Context Protocol). The internet loves to frame them as a cage match — “MCP vs function calling, which one wins?” — and that framing quietly leads a lot of beginners astray.

Here’s the thing: they aren’t really competitors. They solve different parts of the same problem, which is “how does a language model actually do something in the real world instead of just talking about it?” This guide walks through what each one is, why plugins were the awkward first attempt, and how to decide which approach fits your project. No prior infrastructure knowledge required.

The short answer

Function calling is how a model decides which tool to use; MCP is a standard way to make those tools available so any AI client can find and run them. Think of function calling as the model raising its hand and saying “I want to check the weather.” MCP is the universal power outlet that the weather tool plugs into, so the same tool works whether you’re using Claude, a custom app, or your code editor. Plugins were the early, vendor-specific version of this idea that MCP has largely replaced.

If you only remember one sentence: function calling and MCP are not either/or. Most real systems use both, with function calling handling the model’s decision and MCP handling the plumbing.

Function calling explained

Function calling is the mechanism that lets a language model output a structured request to run a specific function, instead of replying with plain text. You hand the model a list of “tools” it’s allowed to use — each described with a name, what it does, and what inputs it needs. When the model decides a tool is the right move, it doesn’t run anything itself. It returns a tidy little JSON object that says “call get_weather with city: Berlin,” and your code is responsible for actually executing that and feeding the result back.

That loop — model proposes, your app executes, result goes back to the model — is the heart of every AI agent. If you want to understand the bigger picture of how models chain these steps together, our explainer on agentic AI covers it, and the loop engineering piece digs into the repeating cycle itself.

The catch with function calling is that the implementation is tied to a specific provider. OpenAI calls it “function calling,” Anthropic calls it “tool use,” and while the concepts line up, the exact schemas and API shapes differ. So if you build twenty tools wired directly into one provider’s format and later want to switch models, you’re rewriting plumbing. There’s nothing wrong with this — it’s fast to prototype and perfectly fine for a single app — but it doesn’t scale across many clients without duplication.

A simplified function-calling tool definition looks roughly like this:

{
  "name": "get_weather",
  "description": "Get the current weather for a city",
  "input_schema": {
    "type": "object",
    "properties": {
      "city": { "type": "string" }
    },
    "required": ["city"]
  }
}

That schema lives inside your application. Your code sends it to the model, reads back the model’s request, runs the actual weather lookup, and returns the answer. Simple, direct, and entirely yours to maintain.

What MCP does differently

MCP (the Model Context Protocol) is an open standard that turns tools into a server any compatible AI client can connect to, discover, and call — without custom integration for each one. Instead of baking a tool’s schema into one app for one provider, you run an MCP server that exposes its tools over a shared protocol. An AI client connects, asks “what can you do?”, gets the list of available tools at runtime, and uses them. The same server works with multiple clients and multiple underlying models.

This is the big shift. With plain function calling, the tool and the app are welded together. With MCP, the tool lives on its own and many clients can share it. Build a database tool once, run one server, and connect your code editor, a chatbot, and an automated pipeline to it — no copy-paste, no per-provider rewrites. If you want the gentler introduction, see what is an MCP server, and when you’re ready to build one, how to build an MCP server walks through it.

A few concrete benefits fall out of this design:

No vendor lock-in. Because MCP is a shared standard, swap the model behind your client and your tools keep working. Your tools aren’t trapped in one provider’s format.
Runtime discovery. Clients ask the server what’s available instead of hard-coding a fixed list, so adding a tool doesn’t mean redeploying every app.
Reuse and governance. Tools can be shared, versioned, and secured independently of any single application.

There’s a fast-growing ecosystem here too — you can browse the best MCP servers or learn how to find MCP servers for things like databases, file systems, and popular SaaS tools. And because a server can reach into your data and systems, MCP security is worth understanding before you connect anything important.

Importantly, MCP doesn’t replace function calling under the hood. When a model decides to use an MCP-provided tool, it’s still the function-calling mechanism doing the deciding. MCP just standardizes how the tool got there in the first place.

And what about plugins?

Plugins were the first mainstream attempt at giving AI models external tools, but each platform built its own incompatible version — and MCP is the open standard that grew up to replace that fragmentation. The most famous example was the ChatGPT plugin system: developers wrote a manifest and an API spec, and the model could call out to external services. It worked, and it proved the demand. But every platform that wanted tool access invented its own plugin format, so a tool built for one assistant didn’t work anywhere else.

That fragmentation is exactly the pain MCP set out to solve. Instead of “a plugin for ChatGPT, a different plugin for this assistant, yet another for that one,” you build one MCP server and any MCP-compatible client can use it. So if you’re reading older tutorials that talk about “plugins,” it’s helpful to mentally translate: the idea (give the model external capabilities) is the same, but the modern, portable way to do it is MCP.

It’s worth noting that the broader tooling world keeps evolving. In ecosystems like Claude Code, you’ll see related-but-distinct concepts — Claude skills, subagents, and MCP servers — that each play a different role. If those blur together for you, the breakdown of Claude skills vs MCP vs subagents untangles which is which.

When do you reach for which?

Use function calling when you’re prototyping a single tool inside one app; reach for MCP when a tool needs to be shared, discovered, or reused across multiple clients and models. Neither choice is permanent — a tool that starts life as inline function calling can graduate to an MCP server later, once it proves useful. Here’s a practical way to decide.

Lean toward plain function calling when:

You’re testing whether a tool is even worth building, and you want zero setup overhead.
The tool only ever serves one application and one model.
You want the simplest possible path from idea to working prototype.

Lean toward MCP when:

The same tool needs to work across several clients — say a code editor, a chat app, and a pipeline.
You want to switch models freely without rewriting your tools.
Tools should be maintained, versioned, or secured on their own, separate from any one app.

And the honest answer for most production systems is both. Function calling handles the model’s tool request inside the conversation, while MCP manages how those tools are routed, discovered, and executed at the infrastructure layer. They’re two halves of one workflow, not competitors. If you’re building something more ambitious, our guide to multi-agent systems shows how these pieces combine, and how to build an AI agent puts it into practice.

FAQ

Is MCP just function calling with extra steps?

No — they operate at different layers. Function calling is how the model expresses its intent to use a tool, and it happens during the conversation. MCP is a transport-and-discovery standard that decides how tools are made available to clients in the first place. When you use an MCP tool, function calling is still doing the deciding underneath; MCP just standardized the connection.

Does MCP replace function calling?

No. MCP relies on function calling rather than replacing it. The model still uses the function-calling mechanism to choose and request a tool — MCP simply provides a portable, vendor-neutral way to expose those tools so any compatible client can use them. The two work together.

Is MCP only for Claude?

No. MCP is an open standard, not an Anthropic-only feature. It was introduced by Anthropic, but it’s designed so any AI client or model can implement it, which is the whole point of avoiding vendor lock-in. A growing range of tools and editors support it. To wire one up in Claude Code specifically, see connect an MCP server to Claude, and check the official docs for the current setup details.

Are ChatGPT plugins still a thing?

The original plugin approach has largely been overtaken by more standardized, portable methods like MCP. The core idea — giving a model access to external services — lives on, but the fragmented, platform-specific plugin formats have given way to a shared protocol. If you’re starting fresh today, building an MCP server is the more future-proof path than a single-platform plugin.

Do I need to know how to code to use MCP?

To build an MCP server you’ll need some coding comfort, but to use existing servers you often don’t — many clients let you connect a pre-built server with a bit of configuration. If you’re approaching this as a non-developer, Claude Code for non-coders is a good starting point, and there’s a whole world of no-code AI agents if you’d rather skip the wiring entirely.

Conclusion

The “MCP vs function calling” debate dissolves once you see the layers clearly. Function calling is the model’s way of saying what it wants to do. MCP is the standardized way of making sure the right tools are available, discoverable, and reusable across clients and models. Plugins were the rough first draft of that idea — useful, but fragmented — and MCP is the open standard that cleaned it up.

For a quick prototype with one tool in one app, plain function calling is the fastest path. The moment you need the same capability across multiple clients, or you want the freedom to swap models, MCP earns its keep. And in most serious systems, you’ll happily run both: function calling for the decision, MCP for the plumbing. Start small, and let your tools graduate to MCP when sharing and reuse start to matter.