"If the model already has function calling, what is MCP for?" It's the sharpest question in this course, it comes up in nearly every MCP interview, and a surprising number of candidates answer it by describing MCP as a newer, better version of function calling. It isn't. They live at different layers — and once you see that, you can also answer the harder follow-up: when should I not bother?
Different layers, not competitors
| Function calling | MCP | |
|---|---|---|
| What it is | a model capability | a connection protocol |
| Scope | inside one API request | between applications and systems |
| Answers | "how does the model request an action?" | "how are actions exposed, discovered and reused?" |
| Who implements | model providers | tool/system owners and AI app builders |
The clinching detail: an MCP server's tools still reach the model as ordinary function calls. MCP doesn't change how the model asks for something. It changes where the tool definition came from and who had to write the integration.
What actually changes in your code
Without MCP: your application defines tool schemas, implements the functions (or clients for external APIs), and wires them into the model call. Every application that needs the same system repeats all of it.
With MCP: the system's owner publishes a server once. Your application connects as a client, asks what's available, and passes those definitions to the model. You wrote no integration for that system — and neither will the next four applications.
What stays exactly the same: the model proposing and your side executing, validation living where execution happens, and descriptions deciding whether the model picks correctly.
Runtime discovery — the genuine upgrade
Plain function calling has tool definitions hard-coded at build time: you write the schemas into your app, and adding a tool means changing and redeploying the app.
MCP capabilities are negotiated at connection time. A client connects, asks the server what it offers, and gets the current list. Add a tool to the server and every connected client can use it — no client redeploys. For a platform team exposing capabilities to several assistants across a company, that alone justifies the protocol.
Wait — my tool surface can change without me deploying anything?
Yes. And the same property that makes discovery convenient makes it a risk when the server isn't yours. A third-party server update can add tools, alter descriptions, or change what an existing tool does — and your assistant picks it up on the next connection.
This is why serious MCP guidance includes: pin server versions, review third-party servers before connecting and again on upgrade, and monitor for capability changes so a new tool appearing triggers a review rather than silently becoming available (lesson 7).
Dynamic capability is a feature for servers you control and an attack surface for servers you don't.
When not to bother
One application with three private tools? Use plain function calling. There's no duplication to remove, so the protocol layer adds moving parts — a server process, a connection lifecycle, another failure mode — for no benefit.
The one-sentence test: will more than one client need this? If yes — or if you want to consume servers other people maintain — MCP earns its place. If no, it's architecture for its own sake.
Selection-round radar: "MCP vs function calling" wants three beats: different layers (mechanism vs plumbing) → MCP tools still arrive as function calls → MCP adds runtime discovery and reuse. Then volunteer the fourth: "and for a single app with a few private tools I'd skip it." That restraint is what distinguishes a strong answer.
Migrating existing tools
Teams often assume migration means rewriting. It doesn't — it's mostly packaging plus curation: wrap your existing functions with MCP registrations, and while you're there, decide which ones should actually be exposed.
That second half is the real work, and it's the same lesson as before: expose a small set of task-shaped tools with clear, non-overlapping descriptions rather than mirroring every internal function. An MCP server is a curated surface for AI clients, not a mirror of your API.
Common mistakes
- Describing MCP as "function calling 2.0" — layers, not versions.
- Believing MCP changes how the model requests actions; it doesn't.
- Adopting MCP for a single app with a handful of private tools.
- Ignoring that a third-party server's tool surface can change under you.
- Migrating by mirroring every internal function as a tool.
- Assuming the protocol removes the need for good descriptions and validation.
Quick recap
| Concept | One-liner |
|---|---|
| Layer distinction | function calling = mechanism; MCP = how tools are exposed and reused |
| Unchanged | model proposes, your side executes and validates |
| MCP adds | runtime discovery, reuse across clients, one server per system |
| The risk | capability drift on servers you don't control — pin and monitor |
| Skip it when | one client, few private tools, no reuse |
| Migration | wrap existing functions, then curate into task-shaped tools |
Practice Zone — PYQs from real selection rounds
Six MCQs and a decision task — MCP or plain tools for four very different projects.
Which statement correctly separates the two?
Asked in
You have one internal app with three private tools. Should you build MCP servers?
Asked in
Which capability does MCP add that plain function calling doesn't have?
Asked in
What new risk does runtime discovery introduce?
Asked in
In an MCP setup, where do the model's tool calls still get executed?
Asked in
Migrating existing tools to an MCP server usually means:
Asked in
Hands-on task:
For each, decide MCP server or plain function calling: 1) a hackathon prototype with two API calls; 2) a company platform team exposing the deployment system to several AI tools; 3) a SaaS product letting customers plug their AI assistants in; 4) a single script that summarizes your own emails.
Asked in
FAQ
Does using MCP lock me into a particular model provider?
No — it's deliberately vendor-neutral, and the tools still reach whichever model you use as ordinary function calls. If anything it reduces lock-in, since your capability layer is independent of the model you happen to be calling.
Can I use MCP servers and hand-written tools together?
Yes, and it's common: MCP servers for shared systems, plain functions for app-specific logic that nobody else needs. From the model's side they all look the same.
Does MCP help with tool selection accuracy?
Only indirectly. It gives you one well-maintained set of descriptions instead of four teams' improvised versions, which usually raises quality — but the model still chooses by reading them, so a bad description is a bad description on any protocol.
Next lesson: what can go wrong, and how the protocol handles trust — Lesson 7: MCP Security →