MCP vs Function Calling: A Protocol Is Not an Interface

MCP vs function calling is not a choice between two ways of doing one job. Function calling is the interface between a model and the program around it: the model writes a request, the program acts on it. MCP is a protocol between two programs: how one finds the tools another offers and calls them across a boundary.

So MCP vs function calling is a question about layers, and a system with MCP in it still uses function calling. The question a tech lead actually faces is narrower and more useful: for this capability, should the agent’s own code hold a plain function, or should the tool live behind a protocol server, ours or someone else’s? This post gives the count that answers half of it and the trust review that answers the other half.

I wrote it for the person who has to sign off on the design. The model’s side of the exchange, message by message, is in the post on what tool calling in LLMs is, and MCP and similar protocols appear here only as labeled examples of a category, with no protocol syntax.

MCP vs function calling: what is the difference?

Function calling decides how a model asks for an action: it reads tool definitions and writes a structured request, and the program around it runs the function or declines. A tool protocol decides how that program learns which tools exist and reaches the code behind them, when that code belongs to another program, another team or another company.

The book this site belongs to draws the line in one sentence. Chapter 6 (“Protocols and Interoperability”, in the full book) defines a protocol as “an agreement about how two independently written programs talk: the message shapes, the sequence of exchanges, the promises both sides keep.” Then it places the agent protocols on top of the model’s request: “What the protocols standardize is everything around that emission: how a capability describes itself, how an agent discovers it, how it is invoked and answered across a process or network boundary.”

The protocol’s own documentation says the same from the other side. MCP’s architecture overview, in the version current on 7 October 2026, states that “MCP focuses solely on the protocol for context exchange—it does not dictate how AI applications use LLMs or manage the provided context” (architecture overview).

What does each layer decide?

Each layer settles a different set of questions, and most arguments in a design review come from answering a protocol question with a model-interface fact, or the reverse. The table is this post’s arrangement.

Question	Function calling (the model interface)	A tool protocol such as MCP (between programs)
Who are the two parties?	A model and the program that sends it requests	An application that hosts the agent, and a server that offers capabilities
What crosses between them?	Tool definitions in, a request to run a tool out	A list of what the server offers, calls, results, change notices
Who sets the format?	The model’s provider or the software serving the model; formats differ by model family	The protocol’s specification, the same for every server
Who writes the tool’s name and description?	You, in your own code	The server’s author, who may be a stranger
Where does the function run?	In your process, or on the provider’s servers for a provider-hosted tool	In the server: a process on your machine or a service elsewhere
How does the agent learn the tool list?	You pass it with each call	The host asks each server; the list can change while the agent runs
What does the model see?	Definitions and results, as text	The same: the host turns the server’s list into definitions for its model
Who decides whether a call runs?	Your code	Still the host; the protocol cannot enforce consent for you
What breaks when you change models?	The request format your code parses	Nothing on the server side; the host adapts definitions to the new model
What breaks when a system changes its interface?	Every agent that wired that system by hand	The one server for that system

The middle rows carry the decision. Behind a protocol the model’s part is unchanged: it reads definitions and writes a request. What moves is authorship and execution, which is a question about trust as much as code.

Does MCP replace function calling?

No. A tool protocol needs function calling, or something equivalent, at the model’s end, because the model still has to say which tool it wants. The host fetches the server’s list, turns it into definitions its model can read, receives the model’s request and forwards it to the right server.

One forum commenter asked the question a tech lead should ask: “What can I do with MCP that I can’t do with the function calling interface in [one provider’s programming interface]? Besides, obviously, grafting function calls into agents I didn’t write; we all understand that’s the value prop of MCP” (Hacker News, 18 October 2025). That is the right frame. Reuse across programs that different people wrote is the benefit, and the rest of this post asks when that reuse is worth what it costs.

Which N×M problem does a protocol solve?

A tool protocol solves the multiplication between applications and the systems they reach: without it, each agent needs its own adapter to each system. It does not solve a second multiplication on the model’s side, where each model family writes tool calls in its own format and each piece of serving software must learn to parse every one.

Chapter 6 starts with a count: three agents, five systems, and “on the order of fifteen” hand-written adapters. “Add a sixth system and you owe three new adapters; add a fourth agent and you owe five”. With one contract in the middle, “the count collapses from a multiplication, M×N, to an addition, M+N.” The protocol’s 2024 announcement stated the same problem: “Every new data source requires its own custom implementation, making truly connected systems difficult to scale” (Anthropic, 25 November 2024).

The second multiplication lives below. Rémi Louf, writing about open models, describes how every model family encodes tool calls differently, so that “The result is N models × M implementations of the same format knowledge, developed in parallel with no shared contract” (Louf, 9 April 2026). A tool protocol leaves that untouched. The server publishes one list; each host still adapts it to the model it runs.

The practical consequence: “MCP makes our tools portable across models” is half true. The server survives a change of model. The host’s model adapter does not, and if your team writes its own host, that adapter is yours.

When does the count favor a protocol?

On count alone, wiring by hand wins whenever there is one agent or one system, ties at two agents and two systems, and loses beyond that. The arithmetic is short: M×N minus (M+N) equals (M−1)(N−1) minus 1, which is positive only when both sides are at least two and not both exactly two.

Agents × systems	Adapters by hand	Protocol implementations	Reading
1 × 1	1	2	By hand
1 × 3	3	4	By hand
2 × 2	4	4	Tie
2 × 4	8	6	Protocol, by 2
3 × 5 (the book’s example)	15	8	Protocol, by 7
4 × 6	24	10	Protocol, by 14

The count compares pieces, not effort. A protocol server can be more work than one small adapter, and the M×N protocol calculator says as much beside every result. What the count shows is how the work grows. One agent with ten systems is still ten adapters against eleven implementations, so a single agent never justifies building your own servers on arithmetic.

It can still justify adopting one. The count assumes you build both sides. When the owner of a system already publishes a server, your share of the work is the client your host probably has already, and the question becomes whether you trust what you are installing.

When is a plain function enough?

A plain function in the agent’s own code is enough when one team owns both ends of the connection and the count does not favor a protocol: one agent, one system, or two of each. Chapter 6 puts it without hedging: “For one tightly coupled integration you fully control, a direct API call is simpler, faster, and easier to debug”.

The rule below is this post’s own, built from the chapter’s ledger and the count above. Ask the questions in order and stop at the first that settles it.

1. Does the far end reason? If it is another agent that takes a goal, plans and owns its method, neither a function nor a tool protocol fits. Chapter 6 calls squeezing it into a tool call “a category mismatch”; use an agent protocol and a written brief.
2. Does someone else already publish this capability as a server? If yes, and you would otherwise write the adapter, adopting the server is the reuse a protocol exists for. It moves the work from writing code to reviewing a dependency, covered in the next section.
3. Does the count favor a protocol, now or after additions already planned? If more than one agent will need more than one system and the hand-wired count exceeds M+N, run your own server for the systems you own.
4. Otherwise, write a function. You wrote its description, you can read its code, and it changes only when you change it.

One case sits between 2 and 3: another team in your company owns the system and publishes no server. The arithmetic does not settle that one. You need a contract with the owner, and whether it takes the form of a protocol server or a versioned API is a conversation between two teams, not a count.

Pick your situation to narrow the table.

What does a tool protocol add to the attack surface?

A tool protocol adds strangers’ words and strangers’ code to the agent. The descriptions a server publishes reach the model as text it reads and obeys, the code behind them runs with whatever access the server has, and both can change after you approved them. A function you wrote has none of those properties, because you are its author.

Chapter 17 (“The Supply Chain”, in the full book) states the difference: “A dependency used to be code that ran. These are code that runs and words the model reads and obeys.” The table sets the two side by side; it is this post’s arrangement of the sources cited in it.

What can go wrong	Your own function	A server someone else wrote
The description carries hidden instructions	You would have to write them yourself	Tool poisoning: “malicious instructions are embedded within MCP tool descriptions that are invisible to users but visible to AI models” (Invariant Labs, 1 April 2025)
The tool changes after approval	Only through your own release	Rug pull: “a malicious server can change the tool description after the client has already approved it” (same source)
One tool steers the use of another	Only if you wrote it so	The same write-up shows a malicious server able to “override instructions provided by other, trusted servers”
The code itself is hostile	You can read it	A local server is a binary “downloaded and executed on the same machine as the MCP client” (security best practices)
Credentials leak to the wrong service	Your credential handling	Token passthrough, which the specification calls “an anti-pattern” and forbids (same page)
The far end is re-decided daily	No	A remote server “is re-decided by someone else every day” (Chapter 17)

How common is the first row? One measurement exists.

Hasan, Li, Fallahzadeh and Rajbahadur scanned 1,899 open-source MCP servers in 2025 and report that “7.2% of servers contain general vulnerabilities, and 5.5% exhibit MCP-specific tool poisoning”; of the eight kinds of vulnerability they found, “only three … overlap with traditional software vulnerabilities” (arXiv 2506.13538). That is one static scan of public repositories at one date, not a rate for the servers your team would pick.

The specification does not carry this load for you. Its overview says that “MCP itself cannot enforce these security principles at the protocol level” (specification, revision of 28 July 2026), and its section on tools says that “clients MUST consider tool annotations to be untrusted unless they come from trusted servers” (tools). Consent, credentials and review stay with whoever builds the host.

A new server can also complete a dangerous combination. If it adds private data, untrusted content or a way to send data out to an agent that already has the other two, it has assembled what the post on the lethal trifecta describes; the lethal trifecta audit runs that check. In Chapter 17’s words, “the trifecta does not care which of its legs arrived preinstalled.”

What else does a protocol cost?

Besides trust, a protocol costs you a moving dependency, a generic interface and an extra hop. Chapter 6 lists the first ones: specs are “young and moving”, the far end drifts, and “a generic interface flattens capabilities toward a lowest common denominator, hides useful specifics behind a schema built for everyone, and inserts indirection you may not need.”

The movement is measurable for the example protocol.

Its specification repository listed five dated revisions on 7 October 2026, from 5 November 2024 to 28 July 2026, about 21 months. The versioning page says each date marks “the last date backwards incompatible changes were made” (versioning). The July 2026 revision removed the opening handshake and protocol-level sessions that the previous revision used (key changes). Under the latest revision a version mismatch between host and server is answered with an error, and someone on your team owns keeping the two in step.

There is also a context cost, though it belongs to the host rather than the protocol. One vendor’s engineering post observed that “Most MCP clients load all tool definitions upfront directly into context” and worked an example from 150,000 tokens down to 2,000 by loading definitions only when needed (Anthropic engineering, 4 November 2025). The post on when a tool should become a skill prices that standing pile.

Worked example: one support agent, three systems

Here is a worked example with illustrative numbers. A tech lead owns one customer support agent. It needs three systems: the team’s own order database, the team’s own refund service, and a ticket tracker bought from a vendor that publishes a protocol server. Next quarter a second agent, for billing operations, will need the same three plus a payments ledger.

Today the count is 3 adapters by hand against 4 implementations (1 + 3), so the count says build by hand. The calculator below opens on this case and also reads the plan: after one more agent and one more system, it is 8 by hand against 6 (2 + 4), and the count tips toward a protocol.

Run each system through the four questions and the answer differs by system, which is the point.

• The order database and the refund service. One team owns both ends and today there is one agent, so question 4 applies: plain functions. The refund changes money, so it gets the tool-design care of Chapter 5, Tools and the Action Space (in the full book), and its description is written in-house.
• The ticket tracker. Question 2 applies: its maker publishes a server. Adopt it, after the review below, and treat its descriptions as the vendor’s words, not yours. Tickets are written by customers, so this server is also the agent’s main source of untrusted content.
• Next quarter. Two agents and four systems make the count 8 against 6. That is the moment to move the team’s own systems behind its own server, and the cost of the move is lower if the functions written today already have the clean names, schemas and error messages a server would expose.

The plan is not “MCP or not”. It is a function now for two systems, a reviewed dependency for one, and a migration with a named trigger.

What should you check before installing someone else’s server?

Check it the way you would check any dependency, and then check the words. The list below condenses Chapter 17’s supply-chain discipline and the specification’s own principles, applied to the decision this post is about. Tick it against the server you are about to install.

The fifth item matters more than it looks. Chapter 6 notes that client and server “name roles in the conversation, and say nothing about geography”: a server may be “a small process on your own laptop with your own privileges, or a hosted service run by a stranger.” Both are the same to the protocol and very different to your security team.

Limits and alternatives

The count and the rule are a first pass, and several things they leave out are worth naming. The count weighs pieces, not hours: a protocol server for a complex system can cost more than three small adapters.

Reuse can disappoint, too. One forum commenter found that public servers often gave “80% of what I wanted” and asked: “if everyone re-implements their own tools, then where’s the value?” (Hacker News, 5 May 2025).

Other contracts exist. An API description format can stand in for a protocol when one team owns both ends; a command-line program plus a written procedure is another option teams use, and the skill post weighs that one. For a far end that reasons, an agent-to-agent protocol is the category to look at, with one published example being Agent2Agent.

The evidence is thin in places. I found one large scan of server vulnerabilities and no public measurement of how often teams actually reach the point where M×N hurts, or of the latency a protocol hop adds in practice. The security figures above are from 2025, on public open-source servers.

And the example protocol is a moving target. Every statement here about it is dated to the revision current on 7 October 2026. The layer distinction is not: whatever the protocols become, a model will still write requests, and a program will still decide whose code answers them.

The takeaway

Treat MCP vs function calling as two questions. Function calling is how your model asks; you will use it either way. The protocol question is whose code answers and who wrote the words describing it. Count the pairs to see whether building your own servers pays, and review any server you adopt as code that runs and as words your model obeys.

Protocols, the count and the honest ledger of their costs are in Chapter 6, Skills, Protocols, and Interoperability (in the full book), and the supply chain is in Chapter 17, Security, Safety, and Guardrails (in the full book). The companion post on what MCP is in AI covers the protocol from the builder’s side. The free guide to tools, skills and protocols collects the related posts and tools, and you can see the formats.