"MCP" and "function calling" get used almost interchangeably, and that causes real confusion when you're designing a system. They're related — but they operate at different layers. Function calling is how a model invokes a tool. MCP is how tools are exposed and shared across applications. Getting the distinction right changes how you architect your AI features.
Quick definitions
Function calling (a.k.a. tool calling) is a model capability: you describe some functions to the model, and when a user's request needs one, the model responds with a structured request to call it. Your code executes the function and feeds the result back. The tools live inside your application, in that provider's format.
Model Context Protocol (MCP) is an open protocol that standardises how AI applications connect to tools and data. Tools live in an MCP server — a separate process — and any MCP-compatible client (Claude Desktop, an IDE assistant, your own agent) can discover and call them over a standard interface.
The key difference
Function calling is in-process and per-app: each application wires each tool in by hand, in each provider's schema. If three apps need the same "look up order status" tool, you implement it three times.
MCP is out-of-process and reusable: you build one server that exposes "look up order status," and every MCP client can use it — no per-app rewiring, no provider-specific glue.
Side by side
| Function calling | MCP | |
|---|---|---|
| Where tools live | Inside each app | In a standalone server |
| Reuse across apps | Reimplement per app | Build once, any client uses it |
| Coupling | Tight (app ↔ tool ↔ provider) | Loose (client ↔ protocol ↔ server) |
| Provider format | Provider-specific schema | Standardised by the protocol |
| Transport | In-process function call | stdio / HTTP between client & server |
| Discovery | Hardcoded per app | Client discovers server's tools at runtime |
| Best for | One app, a few bespoke tools | Shared capabilities across many clients |
How they relate
Here's the part that resolves the confusion: MCP is built on top of tool calling, not instead of it. Under the hood, an MCP client still uses the model's function-calling ability to decide which tool to invoke. MCP standardises the layer around that — how tools are described, discovered, and executed across process boundaries. So it's not "MCP or function calling"; it's "function calling alone, or function calling plus MCP for reuse and decoupling."
When to use plain function calling
- You have one application with a handful of tools specific to it.
- The tools are simple and won't be reused elsewhere.
- You want the least moving parts — no extra server to run.
This is the right default for most single-app features. Don't add MCP just because it's new.
When to use MCP
- Multiple clients need the same tools (a web app, an internal agent, IDE assistants).
- You want to decouple tool implementations from the apps that use them, so teams can evolve them independently.
- You're building on an ecosystem of MCP clients and want your capabilities available to all of them.
- You have existing services (especially in Java/enterprise) you want to expose to AI assistants once — see building an MCP server with Spring AI.
A pragmatic hybrid
Many real systems use both: bespoke, app-specific tools via plain function calling, plus shared enterprise capabilities (search, ticketing, data lookups) behind an MCP server that every internal AI client can reuse. Start with function calling; graduate a tool to MCP when a second consumer appears.
FAQ
Is MCP replacing function calling? No. MCP uses function calling underneath. It standardises how tools are shared across apps — it doesn't remove the model's tool-calling step.
Do I need MCP for a single chatbot? Usually not. For one app with a few tools, plain function calling is simpler. Add MCP when tools need to be reused by other clients.
Can I expose my existing Java services via MCP? Yes — with Spring AI you can wrap existing services as MCP tools. See building an MCP server with Spring AI.
Is MCP tied to one provider? No — it's an open protocol with multiple client and server implementations across the ecosystem.
Function calling is how a model uses a tool; MCP is how tools are shared across your organisation. Use function calling by default, and reach for MCP when reuse and decoupling justify the extra server.
More: building enterprise AI agents, tool calling with Spring AI, and the MCP introduction.
Designing an agent or MCP architecture and want it reviewed? Let's talk.