MCP vs Function Calling vs Plain APIs: What's the Difference?

Introduction

Three terms come up in almost every conversation about connecting an AI model to real systems: plain APIs, function calling and MCP (the Model Context Protocol). They are often presented as competitors, as if a team must pick one. They are not. They sit at different layers, and most production systems that let a model take actions use two or all three of them at once.

All three involve a JSON schema, a name and some arguments, and all three usually end with something calling an HTTP endpoint. The differences are in who defines the tool, who decides to call it, who executes it, and how many applications can reuse the work.

This post explains each layer in plain terms, shows how they fit together, and gives a short decision guide. It is written for CTOs, product leads and engineers deciding how to expose their own systems to AI assistants and agents. If you want the full build guide, our MCP development guide covers architecture, authorization and security in depth.

The Short Answer

• A plain API is how software talks to your system. Your code decides what to call and when. No model is involved.
• Function calling (also called tool use) is a feature of a model provider's API. You describe functions in the request, the model replies with a structured request to call one, and your application runs it.
• MCP is an open protocol that lets an AI application discover tools from a separate server and call them in a standard way. You build the server once, and any MCP-compatible client can use it.

In most MCP clients, the tools fetched from an MCP server are handed to the model through that provider's function calling. The model still "calls a function"; MCP decides where that function came from and how the call reaches your system. And behind the MCP server, there is usually the same plain API you already had.

Plain APIs: Your Code Decides

A REST or GraphQL API is a contract between two programs. A developer reads the documentation, writes code that calls POST /orders or GET /invoices?status=overdue, handles the errors and ships it. Every call is decided in advance by a person writing code.

That is a strength, not a weakness. A plain API call is deterministic, cheap, easy to test and easy to audit. If a workflow always does the same thing (sync new orders to the ERP every five minutes, send a receipt after payment), there is no reason to put a model in the loop. A model adds latency, cost and a small chance of choosing the wrong action.

Plain APIs become a problem only when you want a model to choose actions at runtime. Then someone has to describe each endpoint to the model, translate the model's choice into a real request, and pass the result back. That translation is what function calling provides.

Function Calling: The Model Proposes, Your App Executes

Function calling is built into the major model APIs. OpenAI's function calling guide puts it simply: "A function is a specific kind of tool, defined by a JSON schema." Anthropic's tool use documentation and Google's Gemini function calling docs follow the same pattern with different field names.

The flow is the same everywhere:

1. 1Your application sends the user's message plus a list of tool definitions: a name, a description and a JSON schema for the arguments.
2. 2The model decides whether a tool would help. If so, it returns a structured call with the tool name and arguments instead of (or as well as) text.
3. 3Your application runs the matching code, usually by calling your own API.
4. 4Your application sends the result back to the model.
5. 5The model writes its answer or asks for another call.

The important detail is step 3. The model never touches your system. Google's documentation says it directly: "The model doesn't execute the function itself." Your application holds the credentials, runs the code and decides what to send back. Anthropic draws the same line between client tools, which "run in your application," and server tools such as web search, which run on Anthropic's own infrastructure.

Function calling is the right choice when one application needs a handful of tools that only it will use. A support chatbot that looks up order status and opens a ticket can define two functions in code and be done. There is no extra service to deploy, and options such as OpenAI's strict mode make the model's arguments follow your schema exactly.

Its limits show up as you grow:

• Definitions live inside each application. If your web app, your internal agent and a customer's assistant all need the same "find overdue invoices" tool, each one carries its own copy of the schema and the code.
• Each provider has its own format. Moving from one model provider to another means rewriting tool definitions and the code that handles calls.
• Nobody outside your app can use the tools. A customer who wants to reach your product from their own AI assistant cannot, because your tools only exist inside your codebase.

MCP: Tools Become a Shared Service

MCP moves tool definitions out of the application and into a server. The MCP specification's tools section defines two core messages: a client sends tools/list to discover what a server offers, and tools/call to invoke one. Results come back in a standard shape, with a clear split between protocol errors (an unknown tool, a malformed request) and tool execution errors marked isError: true, which carry feedback the model can use to correct itself and retry.

Three roles matter:

• The host is the AI application the user works in, such as a chat assistant, an IDE or your own agent.
• The client is a connector inside the host. Each client talks to one server.
• The server exposes tools (and optionally resources and prompts) for one system: your CRM, your ticketing tool, your product.

Once a server exists, any host that speaks MCP can connect to it. MCP is also no longer tied to one company. In December 2025 Anthropic, which created it, donated MCP to the Agentic AI Foundation under the Linux Foundation. The foundation was co-founded by Anthropic, Block and OpenAI, and the announcement listed adoption by ChatGPT, Cursor, Gemini, Microsoft Copilot and Visual Studio Code.

The model APIs now support MCP directly too. Anthropic's MCP connector lets a Messages API request connect to remote MCP servers "without a separate MCP client," though it currently supports only tool calls, and the server must be reachable over HTTPS (local stdio servers cannot be connected directly). OpenAI's remote MCP tool does the same in the Responses API, and by default asks for your approval before any data is shared with the server.

When a model API connects to an MCP server, it fetches the server's tool list, gives those tools to the model as functions, and routes the model's calls to the server. Function calling is still doing the selecting; MCP is doing the discovery and transport.

MCP earns its extra moving part when:

• More than one AI application needs the same tools. One server replaces several copies of the same integration.
• You want customers to reach your product from their own assistants. An MCP server is a distribution channel, not just an integration.
• You need one place for authorization, logging and rate limits. The specification says servers must validate all tool inputs, apply access controls and rate limit invocations, and that clients should log tool usage for audit.

Side-by-Side Comparison

Cost, Context and Tool Count

One practical difference is easy to miss: every tool you offer a model costs tokens on every request, whichever layer it came from. Anthropic's tool use pricing page says input tokens include the tools parameter (names, descriptions and schemas), plus a small tool-use system prompt the API adds automatically.

This matters more with MCP, because connecting a server is so easy. Plug in five servers and the model may see dozens of tools it does not need. Anthropic's tool search documentation gives a concrete example: a typical setup with GitHub, Slack, Sentry, Grafana and Splunk servers "can consume ~55k tokens in definitions before Claude does any work," and the ability to pick the right tool "degrades once you exceed 30–50 available tools." Its tool search feature loads only the few tools a request needs, and it works with MCP servers.

Three habits keep this under control at any layer:

• Offer fewer, intent-based tools. One find_overdue_invoices tool beats five thin wrappers around raw endpoints.
• Scope tools to the user and task. The MCP specification lets a server return only the tools the caller's granted scopes permit, so a read-only user never sees write tools.
• Keep tool lists stable. The specification asks servers to return tools in a deterministic order, which helps clients cache the list and improves prompt cache hit rates.

How to Choose

Start from the question "who needs to call this, and who decides when?" rather than from the technology.

1. 1If the steps are fixed and no judgment is needed, use a plain API call or a workflow engine. Keep the model out of it.
2. 2If a model should choose actions, but only inside one application, use function calling. Define a few intent-based tools in code and call your existing API from the handlers.
3. 3If several AI applications, your customers' assistants or third-party agents need the same tools, build an MCP server on top of your API.
4. 4If you are not sure yet, start with function calling but write each tool as a clean function with its own schema. Moving well-designed tools into an MCP server later is mostly packaging work.

Whichever layer you choose, the hard parts are the same. Tools should match user intent, not mirror every endpoint. Descriptions are prompts, so the advice in our prompt engineering guide applies directly. And any tool that changes data needs validation and, for anything with outside effects, a human approval step. The MCP specification says there "SHOULD always be a human in the loop with the ability to deny tool invocations," and the OWASP Top 10 for LLM Applications lists prompt injection (LLM01) and excessive agency (LLM06) as risks that apply to every approach here, not only MCP.

One security point does differ. With function calling, you run all the code, so you control what it does. With MCP, you may be connecting to servers someone else wrote. OpenAI's guide warns that "a malicious server can exfiltrate sensitive data from anything that enters the model's context." Treat third-party MCP servers like any other dependency: use an allowlist, prefer verified publishers and review what each tool does. OWASP lists supply chain (LLM03) as its own risk for the same reason.

How We Approach It

At iTech Soft Solutions we have built and shipped 80+ products since 2016, including 4+ AI products of our own. Our default is the smallest layer that does the job. For a single internal assistant, that is usually function calling over the client's existing API. When a product needs to be reachable from assistants such as Claude and ChatGPT, we build an MCP server.

Feedlio, our AI social media management SaaS that publishes to 12 platforms, is an example. Its MCP server lets a user schedule, reschedule and cancel posts from their own AI assistant, and it is listed on the official MCP Registry. The tools sit on top of Feedlio's own API, so the API, function calling inside the assistant and MCP all play a part in a single request. If you need the same for your product, our MCP server development team can scope it with you. Our projects typically reach an MVP in 8 to 12 weeks, and every launch includes 30 days of post-launch support.

Frequently Asked Questions

Is MCP a replacement for function calling? No. They work at different layers. Function calling is how a model asks for a tool; MCP is how an application discovers tools from an external server and calls them. Most MCP clients pass MCP tools to the model through function calling.

Does MCP replace our REST API? No. An MCP server usually sits on top of your existing API. The API stays the right interface for deterministic integrations, and the MCP server adds model-friendly tool descriptions, clear errors and approval steps for AI clients.

Is function calling enough for an AI agent? For an agent that lives in one application and uses a small set of private tools, yes. Move to MCP when other applications or outside assistants need the same tools, or when you want authorization and logging for tool calls in one place.

Which model providers support MCP? Anthropic and OpenAI both let their APIs connect to remote MCP servers, and assistants and IDEs such as ChatGPT, Cursor, Gemini, Microsoft Copilot and Visual Studio Code have adopted MCP. Feature support differs by client, so test with the ones your users run.

Is MCP more secure than function calling? Not automatically. MCP gives you one place to enforce authorization, rate limits and audit logs, but a badly built server is still unsafe, and third-party servers add supply-chain risk. Both approaches need input validation and human approval for actions with outside effects.

Final Thoughts

Plain APIs, function calling and MCP are not three options for the same job. The API is how your system is reached, function calling is how a model chooses an action, and MCP is how that choice reaches a system the application did not build itself. Whichever you pick, keep the work that matters most the same at every layer: a small set of intent-based tools, clear schemas and a person approving actions that matter.

If you are deciding how to connect your product or internal systems to AI, our AI agents and LLM integration teams can help you choose the right layer and build it. For the broader picture, see our LLM integration guide and AI agents development guide. Contact us to talk through your use case.