MCP vs Function Calling: A Maker's Decision Guide

MCP vs function calling: the real differences

Anyone who has wired up OpenAI's tools parameter or Anthropic's tools array, then read about the Model Context Protocol, asks the same question: isn't MCP just function calling with extra steps? The mcp vs function calling comparisons ranking today are vendor blogs from Prefect, Portkey and Obot AI, each nudging the answer toward their own platform. Here is the neutral version, with rules you can apply today.

MCP vs function calling is a question of layers, not competition. Function calling is the model emitting structured JSON to request a tool call inside your app. MCP is a client-server protocol where a server exposes tools, resources and prompts that any client discovers at runtime. Use function calling for a few tools in one app; use MCP once tools must be shared or governed.

The differences, side by side

Function calling

Function calling is a feature of the LLM API itself. You define tools as JSON schemas, send them with your prompt, and the model decides whether to call one. Prefect's comparison shows how close the schemas look across providers and how different the wrapping is: Anthropic's Python SDK nests the schema under input_schema, while OpenAI's SDK nests the same fields under parameters inside a function object. Support both providers and you either maintain two definitions or write a translation layer.

The model never runs the function. Your application reads the structured output, matches it to real code, executes it, and sends the result back into the conversation. That dispatch loop, plus the schema and the credentials, all live in one process. Obot AI adds a second limit: function calling doesn't natively chain multi-step tool calls into a workflow. You build that logic yourself, and it becomes a bottleneck as the workflow grows.

Function calling is cheap to stand up. Portkey measures a typical implementation at 20-30 lines of Python. There is no server to run and no connection to manage, which is why Prefect recommends it for prototyping: build the tool inline, test it, and only graduate it to an MCP server once it proves valuable.

MCP

The Model Context Protocol is an open standard, described by the spec authors as "a USB-C port for AI." Version 2026-07-28 is the current release, supported by Claude, ChatGPT, Visual Studio Code, Cursor and MCPJam.

MCP splits the pipeline into parts. Per Portkey, the MCP Host is the AI application itself, such as Claude Code or Cursor; the MCP Client maintains a connection to a server; and the MCP Server is a separate process exposing tools, resources and prompts. Obot AI adds a fourth layer to the picture: the data sources underneath, the databases, APIs or files that the tools actually reach into. Tools are executable actions, resources are contextual data, prompts are reusable interaction templates. The latter two have no equivalent in plain function calling.

Discovery is the part function calling can't do. A client calls tools/list to see what a server offers at runtime, and if the server adds or removes a tool it sends notifications/tools/list_changed so every connected client updates without a code change. MCP runs on JSON-RPC 2.0 over two transports: stdio for local servers with near-zero overhead, and Streamable HTTP for remote servers with OAuth. Invocation goes through one universal method, tools/call, regardless of which model generated the request, which removes the per-provider parsing logic function calling requires.

Prefect's worked example makes the payoff concrete: a support-ticket search tool built as an MCP server with FastMCP is one file. Build the same tool as function calling in three separate applications and you get three copies of the schema, three dispatch loops, and three database connections. When the support team adds a filter parameter to the MCP version, every client sees it on its next connection. Prefect also counts the MCP server ecosystem already at hundreds of pre-built servers for services like GitHub, Slack, databases and file systems, so teams can plug in rather than reimplement. Obot AI's tradeoff list is equally direct: more setup complexity, network latency, and a newer, smaller ecosystem than the one built up around individual provider APIs.

Verdict by use case

Prototyping a single-model app. Function calling. You're testing whether a tool is useful at all, so build it inline and iterate before setting up infrastructure.

A coding assistant generating tools from the current project. Function calling. Ephemeral, per-session tools are just data passed with each request; a server for a tool that exists for one conversation adds overhead for no benefit.

A latency-sensitive single-service app. Function calling. It runs in-process. MCP adds a process or network hop, and where every millisecond counts, that's the wrong trade.

A database query tool used by engineering, support and an executive dashboard through different clients. MCP. One server, one source of truth, access control managed at the server level. Prefect calls this a team-shared tool, and it's the kind of integration you'll find listed in the databases category on AI Agents Listing.

Multi-model, multi-team production systems with 10 or more tools. MCP. Portkey's factor table draws the line at five tools for function calling and ten-plus for MCP; below five, inside one app, a server isn't worth the setup cost.

Anything needing an audit trail. MCP. A server behind a gateway is the only architecture here with a natural point to log which agent called which tool, with what arguments, at what time.

Most production systems, in practice. Both. Portkey and Prefect independently describe the same hybrid: function calling handles the model's request inside the conversation loop, MCP handles routing and execution for shared tools, and hot-path, latency-critical calls can bypass MCP entirely. Portkey notes that without MCP, integration complexity across multiple providers and tools tends to grow quadratically; centralizing tool infrastructure in MCP keeps it closer to linear.

If you're picking an editor to build any of this in, Claude Code, Cursor and Windsurf all act as MCP hosts, and adoptable servers turn up across developer tools as well as databases.

What's new (as of 28 July 2026)

The MCP specification's current version is dated 2026-07-28, and the official docs list Claude, ChatGPT, Visual Studio Code, Cursor and MCPJam as supported clients. Portkey's own comparison, published 20 March 2026, flags a terminology shift worth knowing: several platforms and docs now use "tool calling" and "function calling" interchangeably, describing the same mechanism, the model emitting structured output that tells the application which tool to run. Portkey has since become part of PRISMA AIRS AI Gateway under Palo Alto Networks.

Key takeaways

• Function calling is intent generation: the model reads a schema and emits structured JSON; your app executes it. MCP is execution infrastructure: a separate server holds the tool logic, and any client can discover it at runtime.
• The four major providers use four incompatible function-calling formats, OpenAI's tool_calls, Anthropic's tool_use, Gemini's functionCall, Llama's function_call, while MCP invokes every tool through one method, tools/call.
• Portkey's rule of thumb: function calling under five tools and one provider, MCP at ten-plus tools with multiple teams or providers.
• MCP adds a process hop (stdio) or a network hop (Streamable HTTP) that plain function calling doesn't have, so latency-sensitive single-app tools often stay as function calls.
• Most production systems documented by Prefect and Portkey run both: function calling inside the conversation loop, MCP for shared, governed, multi-client tools.

FAQ

Is MCP replacing function calling?

No. Prefect and Portkey both describe them as complementary rather than competing: function calling generates the model's intent to call a tool, and MCP standardizes how that call is discovered and executed once the intent exists. Neither source describes MCP as a replacement for function calling.

Can I use MCP and function calling in the same app?

Yes. Portkey describes this as the common pattern in production: function calling handles the model's request inside the conversation loop, while MCP manages routing and execution at the infrastructure layer, with hot-path calls sometimes going direct to bypass the extra hop.

Which is faster, MCP or function calling?

Function calling, for a single application, since it runs entirely in-process. MCP adds either a local process hop (stdio transport) or a network hop (Streamable HTTP), which both Portkey and Prefect note as the trade-off you accept for portability and discovery.

How many tools before I should switch to MCP?

Portkey's factor table puts function calling's comfort zone at fewer than five tools on a single provider, and MCP's at ten or more tools, especially once multiple teams or model providers are involved. Below that, a 20-30 line function-calling implementation is usually simpler to run.

Does MCP work with multiple AI models?

Yes. An MCP server exposes tools through one protocol that any MCP client can call regardless of which model generated the request, according to the MCP spec, which lists Claude, ChatGPT, Visual Studio Code, Cursor and MCPJam as supported clients.

Compare adoptable servers in the MCP servers hub.