MCP vs function calling: two layers of the same tool call

Function calling is how a model asks to use a tool. MCP (Model Context Protocol) is a standard way to get tools to the app the model runs in. They are not competitors. In a typical MCP setup the model still makes an ordinary function call, and the app passes that call on to an MCP server.

So the useful question is not “MCP or function calling?” It is “does this tool need to live outside my app?”

What is function calling?

Function calling is a feature of a model’s API (the programming interface your app uses to talk to the model). OpenAI also calls it tool calling; Anthropic calls it tool use. You send the model a question plus a short list of tools. Each tool has a name, a description, and a schema: a strict description of which inputs it accepts.

If the model decides it needs a tool, it does not answer in prose. It replies with a structured request, for example: call get_order_status with order_id: "A-1043".

The model never runs anything itself. OpenAI’s guide lists five steps, and the third is “Execute code on the application side with input from the tool call.” Anthropic’s documentation says Claude “returns a structured call that your application executes.” Your code does the work, sends the result back, and the model writes the final answer.

What is MCP?

MCP is an open protocol that Anthropic open-sourced on 25 November 2024 for connecting AI apps to outside tools and data. It has three roles:

• The host is the AI app you use, such as a desktop chat app or a code editor.
• The server is a separate program that offers tools (actions), resources (data to read), and prompts (templates).
• The client is a small connector inside the host. The host runs one client per server.

A client asks a server what it offers with a request called tools/list, and runs a tool with tools/call. Messages travel over stdio, where the server runs as a local program on the same machine, or over HTTP, where the server runs somewhere on a network. MCP meaning is the full dictionary entry.

How do the two fit together? One call, traced

Imagine a hypothetical bike shop that wants its assistant to answer “where is my order?”

With plain function calling, the developer writes a get_order_status function inside the shop’s app and describes it in the API request. The model replies with a tool call. The app runs the function against the order database and sends the result back. Everything lives in one codebase, owned by one team.

With MCP, the same function moves into a small MCP server. When the assistant starts, its client sends tools/list and receives the tool’s name, description, and input schema. The host hands that list to the model as ordinary tool definitions. The model replies with the same tool call as before. The client turns it into a tools/call request, the server runs the lookup, and the result flows back.

This is not a simplification made for this page. The official MCP tutorial for building a client does exactly this: it converts the server’s tool list into Claude’s tool format, then forwards each tool request the model makes to the server.

Question	Plain function calling	With MCP
Where does the tool’s code live?	Inside your app	In a separate MCP server
Who writes the tool description?	Your app	The server
Who can use the tool?	That one app	Any MCP-capable app that connects
What does the model produce?	A structured tool call	The same structured tool call
Who runs the tool?	Your app	The server, when the host forwards the call
How does the call travel?	A function call in your code	stdio (local) or HTTP (remote)
Who decides what the tool may do?	You	Still you

The one line to remember: function calling is the model’s request; MCP is the delivery route for the tool.

Some platforms now do part of the wiring for you. OpenAI lists access to an MCP server among its built-in tools, and Anthropic offers an MCP connector that reaches remote MCP servers from its API without a separate client. The model still asks for a tool the same way. The platform does the client’s job.

When is plain function calling enough?

When one app uses its own tools. If your product calls three internal functions, written and deployed by the same team, a separate server adds a process to run, a connection to secure, and a version to track. It buys you nothing.

A quick test: would anyone ever want this tool inside a different AI app? If the honest answer is no, keep it a function.

When does MCP earn its place?

When the same tool has to work in more than one place. Suppose the bike shop wants its order lookup in the customer chat, in the code editor its developers use, and in the desktop assistant the support lead runs. One MCP server replaces three separate integrations. The specification says MCP takes some inspiration from the Language Server Protocol, which did the same job for programming languages across code editors.

MCP also earns its place when someone else builds the tool. Ready-made servers exist for common systems (Anthropic’s launch post in 2024 already shared servers for Google Drive, Slack, GitHub, and Postgres), and a host can attach one without new code on your side. Ready-made is not the same as reviewed, which is the next section. What is an MCP connector? covers how that attachment works in each app.

What does MCP not change?

Myth: MCP makes tool calls safe. Fact: the specification says plainly that “MCP itself cannot enforce these security principles at the protocol level.” It asks hosts to get the user’s consent before invoking a tool, and requires servers to validate inputs, implement access controls, and limit how often tools can be called. A tool that can read your whole customer database is exactly as wide over MCP as it was as a function.

Myth: MCP replaces function calling. Fact: in the traced call above, the model still makes the function call. MCP moved the tool, not the request.

Myth: tool descriptions are harmless labels. Fact: the model reads them as instructions it may follow, and the specification says descriptions of tool behaviour “should be considered untrusted, unless obtained from a trusted server.” A server you did not write puts someone else’s text in front of your model. MCP explained for founders covers how to review one.

What matters either way: a contract per tool

Whichever route you choose, the risk sits in what the tool can do, not in how the request travels. The Agentic Codebase, one of Len’s books (available now), is about organising code repositories where people and AI agents work side by side. Its chapter on MCP makes the point this page rests on: a function only tells you the agent can call it, while a contract tells you it can call it safely and what happens when it goes wrong.

You do not need the book to use its checklist. For each tool, write down:

1. Scope. What it may read and change, and what it must never touch. If a permission is on both lists, the deny list wins.
2. Inputs and outputs. Typed and bounded, so “all transactions” becomes “the latest 50, with a way to ask for more”.
3. Auth. Whose credentials it uses. For a remote server: a token that works for that server only.
4. Timeout. How long to wait, and what happens when time runs out.
5. Idempotency, for anything that changes data: a unique key per operation, so a retry after a network error cannot refund a customer twice.
6. Named failure modes. “Not found: return nothing, never invent a record.” “Rate limited: wait and report.”
7. Owner. One named person.

Applied to the bike shop: get_order_status may read one order by its number and nothing else. It returns status and delivery date only, gives up after a few seconds, and has no write path, so it needs no idempotency key. It says “not found” instead of guessing, and the developer who wrote it owns it.

That fits in a short text file next to the code. It is the same file whether the function stays in the app or moves to an MCP server.

Try this today (15 minutes)

Pick one tool your AI setup can call.

1. Write down where it lives: in your app’s code, or in an MCP server.
2. Ask the reuse question. Does any other AI app need it? If not, and it runs as an MCP server you built yourself, you may be maintaining a server for nothing. If several apps need it and you copied it into each one, that is the case for MCP.
3. Fill in the seven contract lines above. Any line you cannot fill is the thing to fix before you add another tool, over any protocol.

Cite this:MCP vs function calling: two layers of the same tool call.Len P. van der Hof. https://lenvanderhof.com/en/blog/mcp-vs-function-calling/ · Published 25 September 2026.