COMPARISON

Function Calling vs MCP

Function calling is a model-API feature for requesting structured calls to functions you define. MCP is a protocol for packaging, sharing and discovering tools across AI applications. They work together.

Short answer: Function calling is how a model asks for a tool to be run (model ↔ your app). MCP is how an AI app finds and connects to tools hosted elsewhere (app ↔ tool servers). An MCP-enabled app typically uses function calling under the hood to let the model use MCP tools.

At a glance

Function callingMCP
What it isA feature of a model APIAn open protocol between AI apps and tool servers
ConnectsModel ⇄ your application codeAI application (client) ⇄ tool/data server
Where tools are definedIn your request, in your codeIn an MCP server, discovered at run time
Reuse across appsYou re-implement per app or providerOne server works with any compatible client
Beyond toolsTools onlyTools, resources, prompts, and more
Who runs the toolYour codeThe MCP server (which may be local or remote)
Standardised?Pattern is similar, formats differ by providerYes, defined by a published specification

They sit at different layers, so the question is usually not "which" but "do I need the second layer?"

What is each?

Function calling: you list functions (name, description, JSON Schema) in a model request; the model may reply with a structured call; your code executes it and returns the result.

MCP: a protocol where an MCP server exposes tools (plus resources and prompts) and a client in the AI application lists and calls them over a standard transport.

Key differences

Think of a request's journey with MCP in the picture:

  1. The host connects to MCP servers and lists their tools.
  2. The host passes those tool definitions to the model using the model API's function-calling feature.
  3. The model returns a function call.
  4. The host forwards it to the right MCP server as a tools/call request.
  5. The result flows back to the model.

So MCP does not replace function calling; it standardises where the tools come from and how the application reaches them.

Other differences:

  • Coupling. Function-calling tools are typically in the same codebase as your app; MCP tools can live in independent, separately maintained servers.
  • Distribution. MCP makes it practical to share a tool as a package or service for many clients.
  • Overhead. MCP adds a protocol layer, process or network hop, and security review of each server. For a handful of in-app functions, that is unnecessary.

When to choose which

  • One app, a few custom functions, full control → function calling alone.
  • You want your integration usable in many AI apps → build an MCP server.
  • You want ready-made integrations (files, repos, databases, SaaS) → use MCP servers you trust.
  • You need only structured output, no external action → function calling (or a structured-output feature) is enough.
  • You are building an agent platform that third parties extend → MCP is a natural fit.

Example

A team builds an internal helpdesk bot. Version 1 defines two functions in its backend (get_ticket, add_note) and uses function calling directly — about a day of work, no extra infrastructure. Later, the same capabilities are requested inside the company's IDE assistant and chat client. They wrap the ticket system once as an MCP server; all three clients now use it. The helpdesk bot may still call it through the same MCP connection, or keep its direct functions; the model API call is still function calling either way.

Common mistakes

  • Treating them as mutually exclusive.
  • Adopting MCP for a tiny single-app project.
  • Assuming an MCP tool is safer than a local function; its code and descriptions come from elsewhere and need review (What is Prompt Injection?).
  • Exposing too many tools from one server.
  • Forgetting that either way, your application must validate arguments and enforce permissions.