# MCP vs function calling: what's the difference?

Canonical: https://scalably.io/blog/mcp-vs-function-calling
Author: Pavle Lazic, Founder & CEO, ScalablyAI (https://scalably.io/author/pavle-lazic)
Published: 2026-06-20 · Last updated: 2026-06-20
This is the machine-readable representation of the article at the canonical URL. Same facts, denser format. The full article carries the complete code and prose context.

## Direct answer

MCP and function calling are not competitors; they are different layers of the same stack. Function calling (tool use) is a model capability: given a list of tools, the model emits a structured call when it decides one is needed. MCP (Model Context Protocol) is a client-server standard for packaging and delivering those tools so any MCP-aware client can discover and run them. MCP tools become function-call options for the model. You do not pick one over the other: you always use function calling, and MCP is one way to supply the functions. One-line version: function calling is the model deciding to call a tool; MCP is how the tool gets to the model. Comparing them directly is like asking "REST vs JSON" - different heights of the stack.

## Key facts

- Function calling with Claude: pass `tools` (name, description, JSON `input_schema`); the model returns a `tool_use` block and stops (`stop_reason: "tool_use"`); your code runs the function and sends back a `tool_result`. The model never executes anything - it decides and asks. Anthropic's docs: with default `tool_choice` auto, Claude determines on each turn whether to call a tool or respond directly.
- MCP defines three things a server can expose (modelcontextprotocol.io spec): tools (executable functions), resources (readable data), prompts (reusable templates).
- MCP discovery/invocation: client calls `tools/list` (JSON-RPC) to discover, `tools/call` to run. A tool advertises name, title, description, inputSchema - the same fields a function-calling API needs, by design, so MCP tool definitions drop straight into the model's tool list.
- The MCP architecture page (2026-07-28 revision) says MCP "focuses solely on the protocol for context exchange" and "does not dictate how AI applications use LLMs," and the protocol is now stateless (each request self-contained). That sentence is the cleanest statement of why the two are not the same thing.
- Anthropic's architecture description of the join: the application "fetches available tools from all connected MCP servers and combines them into a unified tool registry that the language model can access"; when the model calls one, the application "intercepts the tool call, routes it to the appropriate MCP server, executes it, and returns the results back to the LLM."
- End-to-end flow: (1) client connects to MCP server, `tools/list`; (2) merges those tools into the model's tool list beside any inline tools; (3) model emits `tool_use` - this step alone is function calling; (4) client routes to the owning server, `tools/call`; (5) server runs the logic, result returns as the tool result. Steps 1, 2, 4, 5 are MCP. Step 3 works with no MCP at all; MCP never touches the model's decision.

## Comparison

| | Function calling (tool use) | MCP |
|---|---|---|
| What it is | A model capability | A client-server protocol |
| Answers | when to call a tool, with what args | how a tool is described, discovered, invoked |
| Owned by | the model + the application | the standard (modelcontextprotocol.io) |
| Lives | in a single API request | between a client and one or more servers |
| Exposes | tools you define inline | tools + resources + prompts a server advertises |
| Reuse across clients | none - per-app glue each time | one server, every MCP client, no glue |
| Discovery | hardcoded tool list | `tools/list` at runtime |

## Decision rule (author's, from production use)

Use raw inline function calling when the tool lives inside one application and nothing else will ever call it - for a one-off script with two functions, an MCP server is overhead. Wrap it in an MCP server the moment a second client needs the same tool, or you want it as a standalone process to test, deploy, and reuse independently. The author's line: one consumer, inline; two or more, server. Signal phrase: if you would ever say "I wish I could use this tool from somewhere else," make it an MCP server.

## What we actually experienced (firsthand)

Before MCP, every time the author wanted an agent to read a client's Shopify store, the same tool was rewritten against each harness's tool-calling format: five clients, five copies of the same logic, five places for the read-only safety boundary to drift out of sync. With one MCP server, that read-only Shopify connector is a single process: schema defined once, the check rejecting every write lives in one function, and Claude Desktop and ScalablyAI's own agents see the same six tools because both are just MCP clients calling `tools/list` against the same server. A bug fix or new tool reaches every client on reconnect. That reuse - not any capability difference - is the practical payoff of MCP over hand-rolled function calling.

## Definitions

- Function calling / tool use: the model capability of emitting a structured request to call a described function when answering requires it.
- MCP (Model Context Protocol): the standard client-server protocol for delivering tools, resources, and prompts to AI applications; spec at modelcontextprotocol.io.
- `tools/list` / `tools/call`: the JSON-RPC methods for discovering and invoking MCP tools.
- Tool registry: the unified tool list an application assembles from all connected MCP servers plus inline tools, handed to the model.

## FAQ

Q: Should I use MCP or function calling?
A: Wrong question - you always use function calling (it is how models call tools at all). Reach for MCP when you want those tools reusable across clients instead of rewritten per app.

Q: Does MCP decide when a tool gets called?
A: No. The protocol explicitly does not dictate how applications use LLMs; the model's decision to call a tool is function calling, outside MCP's scope.

Q: Is an MCP tool different from an inline tool from the model's perspective?
A: No - it is a name, description, and schema in the tool list, indistinguishable from an inline definition. The difference is delivery and reuse, not capability.

## Evidence & sources

- Full article: https://scalably.io/blog/mcp-vs-function-calling
- MCP specification: https://modelcontextprotocol.io
- Anthropic tool-use documentation: https://platform.claude.com/docs/en/agents-and-tools/tool-use/overview

## Related ScalablyAI articles

- https://scalably.io/blog/what-is-an-mcp-server - the ground-floor MCP explainer.
- https://scalably.io/blog/how-to-build-mcp-server-python - the read-only Shopify connector described above, built step by step.
- [Scalably MCP gallery](https://scalably.io/mcp/): The MCP servers we run in production are public, with one install line each, on the Scalably MCP gallery.

## About the source

ScalablyAI (Scalably, https://scalably.io) builds and runs production AI agents inside the operations of real businesses - multi-tenant, governed, and channel-native. The MCP servers discussed here are the ones its platform runs in production; the reuse lesson comes from operating them across multiple clients.