MCP vs Function Calling: What's the Difference and Which Should You Use?

If you've been building with AI agents, you've likely encountered both function calling and MCP (Model Context Protocol). They look similar on the surface — both let an AI agent call tools and get structured data back. But they solve fundamentally different problems, and picking the wrong one adds unnecessary complexity to your stack.

Here's the clearest way to think about it: function calling is a model feature; MCP is a distribution format.

What function calling actually is

Function calling (also called tool use) is a capability built into the LLM itself. You define a set of functions in JSON Schema format, pass them to the model alongside your prompt, and the model can decide to "call" one of them by returning a structured JSON payload instead of plain text.

Your application code then receives that payload, executes the actual function, and feeds the result back to the model. The model never actually calls anything — it just outputs structured JSON that tells your code what to call.

// You define the tool schema
const tools = [{
  name: "get_weather",
  description: "Get current weather for a city",
  input_schema: {
    type: "object",
    properties: { city: { type: "string" } },
    required: ["city"]
  }
}]

// Model returns: { name: "get_weather", input: { city: "London" } }
// Your code executes the actual API call and returns the result

Function calling is entirely contained within a single API call and a single application. The tool definitions live in your code. Nobody else can use them unless you ship them your code.

What MCP actually is

MCP is a protocol for distributing tools. Instead of defining tools inside your application, you run a separate server that exposes tools over a standardised JSON-RPC interface. Any MCP client — Claude Desktop, Cursor, a custom agent — can connect to that server and use its tools without you writing any glue code.

// MCP server exposes tools via HTTP
POST /mcp
{ "method": "tools/list" }
→ returns available tools

{ "method": "tools/call", "params": { "name": "ask_site", "arguments": { ... } } }
→ executes tool, returns result

// Any MCP client can connect — no integration code needed

The key difference: MCP tools are reusable across applications. You build the server once and any agent that speaks MCP can call it. Function calling tools are private to the application that defines them.

A concrete comparison

When to use function calling

Use function calling when the tools are specific to your application and won't be used by anything else:

• Querying your own database with your own auth logic
• Calling internal APIs that require your credentials
• Manipulating application state (creating a record, updating a field)
• Tools that only make sense in the context of your specific product

The advantage is simplicity — no server to deploy, no protocol to implement, just a JSON schema alongside your prompt. For tools that are private to your app, this is the right call.

When to use MCP

Use MCP when you want any agent — not just one application — to be able to use your tools:

• You're building a tool that other developers will use in their agents
• You want your documentation, product, or API to be queryable by Claude Desktop, Cursor, or any MCP client
• You're building infrastructure — search, indexing, data retrieval — that multiple apps should share
• You want users to be able to add your tool with a URL, not by installing a package or writing glue code

AgentReady is a good example. It exposes tools (ask_site, submit_site, refresh_site) via an MCP server at a URL. Any agent — Claude, Cursor, a custom script — can connect to that URL and immediately query any indexed website. If those tools were implemented as function calling schemas, each developer would have to copy-paste the schema and host the execution logic themselves.

They're not mutually exclusive

Most production agents use both. Function calling handles the private, app-specific logic. MCP handles shared, hosted tools that the agent can reach over the network.

A typical setup: your agent uses function calling to query your internal database and MCP to query external documentation, APIs, or services. The LLM sees all the tool definitions in its context window — it doesn't know or care whether a tool is function-called or MCP-backed. Both produce the same structured call-and-response pattern from the model's perspective.

// Claude Desktop config — mixing both patterns
{
  "mcpServers": {
    "agentready": {
      // MCP: shared tool, hosted externally
      "command": "npx",
      "args": ["-y", "@agentreadyweb/mcp"]
    }
  }
}
// Function calling: private tools defined in your system prompt
// Both work together in the same agent session

The MCP 2026 spec makes this cleaner

The MCP 2026-07-28 release candidate introduces a stateless core — MCP servers can now run behind a plain load balancer, and clients can cache tools/list responses. This makes the operationally messier parts of MCP (sticky sessions, server state) a solvable problem rather than a fundamental constraint. If you've avoided MCP for production because of scaling concerns, the new spec addresses most of them.

Quick decision guide

Use function calling if:

• The tool is private to your application
• You control both the definition and the execution
• No other agent or developer needs to use it

Use MCP if:

• You want the tool reusable across agents and applications
• You're exposing your product's data or functionality to external agents
• You want users to connect with a URL, not by writing code