--- title: "MCP vs function calling: the difference, with an example | Len P. van der Hof" description: Function calling is how a model asks to use a tool. MCP is a standard route for getting tools to the app. The difference, a worked example, and when MCP pays. image: "https://lenvanderhof.com/media/generated/blog-hero-mcp-vs-function-calling-v2.0d6f2051c33e.wide.webp" --- [AI Systems](https://lenvanderhof.com/en/blog/category/ai-systems/) Research guide # MCP vs function calling: two layers of the same tool call In most MCP setups the model still makes a function call. MCP changes where the tool lives, not how the model asks for it. Len P. van der HofPublished 25 September 20268 min read One request. The question is how it travels. Direct answer Function calling (also called tool calling) is a model replying with a structured request to run a named tool with specific inputs; your application runs the tool and sends back the result. MCP, the Model Context Protocol, is an open standard for putting tools in a separate server that any compatible AI app can discover and call. They are layers, not rivals: under MCP the model still makes a function call, and the app forwards it to the server. Neither layer decides what a tool may do. ## Key takeaways - Function calling is the model's request. MCP is the delivery route for the tool. - Under MCP the model still makes a function call; the app forwards it to an MCP server. - One app with its own tools rarely needs MCP. A tool that several AI apps or teams must share usually does. - Neither layer sets permissions. Write a contract per tool: scope, limits, timeout, failure modes, owner. **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](https://lenvanderhof.com/en/blog/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. QuestionPlain function callingWith MCPWhere does the tool’s code live?Inside your appIn a separate MCP serverWho writes the tool description?Your appThe serverWho can use the tool?That one appAny MCP-capable app that connectsWhat does the model produce?A structured tool callThe same structured tool callWho runs the tool?Your appThe server, when the host forwards the callHow does the call travel?A function call in your codestdio (local) or HTTP (remote)Who decides what the tool may do?YouStill 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?](https://lenvanderhof.com/en/blog/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](https://lenvanderhof.com/en/blog/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](https://lenvanderhof.com/books/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/](https://lenvanderhof.com/en/blog/mcp-vs-function-calling/) · Published 25 September 2026. ## Sources 1. [Function calling](https://developers.openai.com/api/docs/guides/function-calling) · OpenAI 2. [Tool use with Claude](https://platform.claude.com/docs/en/agents-and-tools/tool-use/overview) · Anthropic 3. [Introducing the Model Context Protocol](https://www.anthropic.com/news/model-context-protocol) · Anthropic 4. [Specification, MCP revision 2026-07-28](https://modelcontextprotocol.io/specification/2026-07-28) · Model Context Protocol 5. [Tools, MCP specification 2026-07-28](https://modelcontextprotocol.io/specification/2026-07-28/server/tools) · Model Context Protocol 6. [Transports, MCP specification 2026-07-28](https://modelcontextprotocol.io/specification/2026-07-28/basic/transports) · Model Context Protocol 7. [Build an MCP client](https://modelcontextprotocol.io/docs/develop/build-client) · Model Context Protocol 8. [MCP meaning](https://lenvanderhof.com/en/blog/mcp-meaning/) 9. [What is an MCP connector?](https://lenvanderhof.com/en/blog/what-is-an-mcp-connector/) 10. [The Agentic Codebase](https://lenvanderhof.com/books/the-agentic-codebase/) ## Further reading - [MCP meaning](https://lenvanderhof.com/en/blog/mcp-meaning/) - [What is an MCP connector?](https://lenvanderhof.com/en/blog/what-is-an-mcp-connector/) - [MCP explained for founders](https://lenvanderhof.com/en/blog/mcp-explained-for-founders/) - [The Agentic Codebase](https://lenvanderhof.com/books/the-agentic-codebase/) About the author ## [Len P. van der Hof](https://lenvanderhof.com/en/authors/len-p-van-der-hof/) Entrepreneur, AI Innovator and Venture Builder Len P. van der Hof builds practical AI systems, digital ventures and evidence-informed tools for founders. ```json { "@context": "https://schema.org", "@graph": [ { "@type": "Person", "@id": "https://lenvanderhof.com/#person", "name": "Len P. van der Hof", "alternateName": [ "Len van der Hof", "L.P. van der Hof", "Leendert Pieter van der Hof" ], "honorificSuffix": "MSc", "url": "https://lenvanderhof.com/", "image": [ "https://lenvanderhof.com/photos/len-portrait-1.jpg", "https://lenvanderhof.com/photos/len-portrait-2.jpg", "https://lenvanderhof.com/photos/len-portrait-3.jpg", "https://lenvanderhof.com/photos/len-portrait-4.jpg", "https://lenvanderhof.com/photos/len-speaking.jpg", "https://lenvanderhof.com/photos/len-hero.jpg" ], "jobTitle": "Entrepreneur, AI Innovator and Venture Builder", "description": "Len P. van der Hof, MSc, is a Dutch entrepreneur and AI innovator in Zwijndrecht. He builds ReasonKit, MindSesh, Undominated.ai, books under his name, the fiction imprint LPH98.lifestyle, and technology ventures through LPH98.ventures. Eleven titles in Systems for the Strategic Self are available now, in English and Dutch.", "address": { "@type": "PostalAddress", "addressLocality": "Zwijndrecht", "addressCountry": "NL" }, "alumniOf": { "@type": "CollegeOrUniversity", "name": "Rotterdam School of Management, Erasmus University" }, "knowsAbout": [ "Artificial intelligence", "AI agents", "Agentic AI systems", "LLM routing", "SEO", "Generative engine optimization", "Answer engine optimization", "Venture building", "Founder performance", "Founder psychology", "Evidence-based decision-making" ], "sameAs": [ "https://www.linkedin.com/in/lenvanderhof/", "https://x.com/LenvanderHof", "https://www.youtube.com/channel/UCTG20buKqYYbitqqf7l3zJA", "https://www.instagram.com/Lenvanderhof/", "https://www.threads.com/@lenvanderhof", "https://github.com/Lenvanderhof", "https://huggingface.co/LPH98", "https://www.npmjs.com/~lenvanderhof", "https://www.goodreads.com/author/show/70983905.Len_P_van_der_Hof", "https://www.amazon.com/author/lenvanderhof", "https://www.bol.com/nl/nl/b/len-p-van-der-hof-msc/609879394/", "https://bsky.app/profile/lenvanderhof.com", "https://mastodon.social/@Lenvanderhof", "https://crates.io/users/Lenvanderhof", "https://cursor.com/@Lenvanderhof", "https://medium.com/@Lenvanderhof", "https://gitlab.com/Lenvanderhof", "https://hub.docker.com/u/lenvanderhof/", "https://dev.to/lenvanderhof", "https://www.facebook.com/Lenvanderhof", "https://soundcloud.com/Lenvanderhof" ], "affiliation": [ { "@id": "https://lenvanderhof.com/#publisher" }, { "@id": "https://lenvanderhof.com/#mindsesh" }, { "@id": "https://lenvanderhof.com/#lifestyle" } ] }, { "@type": "WebSite", "@id": "https://lenvanderhof.com/#website", "url": "https://lenvanderhof.com/", "name": "Len P. van der Hof", "description": "Len P. van der Hof, MSc, is a Dutch entrepreneur and AI innovator in Zwijndrecht. He builds ReasonKit, MindSesh, Undominated.ai, books under his name, the fiction imprint LPH98.lifestyle, and technology ventures through LPH98.ventures. Eleven titles in Systems for the Strategic Self are available now, in English and Dutch.", "inLanguage": [ "en", "nl" ], "publisher": { "@id": "https://lenvanderhof.com/#person" } }, { "@type": "Organization", "@id": "https://lenvanderhof.com/#publisher", "name": "LPH98.ventures", "url": "https://lph98.ventures", "founder": { "@id": "https://lenvanderhof.com/#person" } }, { "@type": "Organization", "@id": "https://lenvanderhof.com/#mindsesh", "name": "MindSesh", "url": "https://mindsesh.net", "founder": { "@id": "https://lenvanderhof.com/#person" } }, { "@type": "SoftwareApplication", "@id": "https://lenvanderhof.com/#reasonkit", "name": "ReasonKit", "url": "https://reasonkit.sh", "creator": { "@id": "https://lenvanderhof.com/#person" } }, { "@type": "SoftwareApplication", "@id": "https://lenvanderhof.com/#undominated", "name": "Undominated.ai", "url": "https://undominated.ai", "creator": { "@id": "https://lenvanderhof.com/#person" } }, { "@type": "Organization", "@id": "https://lenvanderhof.com/#lifestyle", "name": "LPH98.lifestyle", "url": "https://lph98.lifestyle", "founder": { "@id": "https://lenvanderhof.com/#person" } }, { "@type": "ImageObject", "@id": "https://lenvanderhof.com/en/blog/mcp-vs-function-calling/#primaryimage", "url": "https://lenvanderhof.com/media/generated/blog-hero-mcp-vs-function-calling-v2.0d6f2051c33e.wide.webp", "contentUrl": "https://lenvanderhof.com/media/generated/blog-hero-mcp-vs-function-calling-v2.0d6f2051c33e.wide.webp", "representativeOfPage": true }, { "@type": "BreadcrumbList", "@id": "https://lenvanderhof.com/en/blog/mcp-vs-function-calling/#breadcrumb", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://lenvanderhof.com/" }, { "@type": "ListItem", "position": 2, "name": "Blog", "item": "https://lenvanderhof.com/en/blog/" }, { "@type": "ListItem", "position": 3, "name": "AI Systems", "item": "https://lenvanderhof.com/en/blog/category/ai-systems/" }, { "@type": "ListItem", "position": 4, "name": "MCP vs function calling: two layers of the same tool call", "item": "https://lenvanderhof.com/en/blog/mcp-vs-function-calling/" } ] }, { "@type": "WebPage", "@id": "https://lenvanderhof.com/en/blog/mcp-vs-function-calling/#webpage", "url": "https://lenvanderhof.com/en/blog/mcp-vs-function-calling/", "name": "MCP vs function calling: two layers of the same tool call", "description": "Function calling is how a model asks to use a tool. MCP is a standard route for getting tools to the app. The difference, a worked example, and when MCP pays.", "isPartOf": { "@id": "https://lenvanderhof.com/#website" }, "primaryImageOfPage": { "@id": "https://lenvanderhof.com/en/blog/mcp-vs-function-calling/#primaryimage" }, "breadcrumb": { "@id": "https://lenvanderhof.com/en/blog/mcp-vs-function-calling/#breadcrumb" }, "inLanguage": "en-GB" }, { "@type": "BlogPosting", "@id": "https://lenvanderhof.com/en/blog/mcp-vs-function-calling/#article", "mainEntityOfPage": { "@id": "https://lenvanderhof.com/en/blog/mcp-vs-function-calling/#webpage" }, "headline": "MCP vs function calling: two layers of the same tool call", "description": "Function calling is how a model asks to use a tool. MCP is a standard route for getting tools to the app. The difference, a worked example, and when MCP pays.", "datePublished": "2026-09-25T14:00:00.000Z", "author": { "@id": "https://lenvanderhof.com/#person" }, "publisher": { "@id": "https://lenvanderhof.com/#person" }, "image": [ "https://lenvanderhof.com/media/generated/blog-hero-mcp-vs-function-calling-v2.0d6f2051c33e.square.webp", "https://lenvanderhof.com/media/generated/blog-hero-mcp-vs-function-calling-v2.0d6f2051c33e.landscape.webp", "https://lenvanderhof.com/media/generated/blog-hero-mcp-vs-function-calling-v2.0d6f2051c33e.wide.webp" ], "articleSection": "AI Systems", "inLanguage": "en-GB" } ] } ```