Function calling wires one tool into one app. MCP is the plug that makes that wiring reusable everywhere. Function calling lets a model invoke one tool you defined inside one app. MCP, the Model Context Protocol, is an open standard that lets you write a tool server once and connect it to any AI app that speaks the protocol, so you stop rebuilding the same integration for every app.
The mental model: function calling is the cable, MCP is the USB-C port. One you rebuild per device; one you plug in anywhere. (1) Function calling = a model picks a tool and supplies arguments; your app runs it. (2) MCP = a standardized client-server protocol so one tool server works across many AI apps. (3) They are not rivals; MCP servers expose tools, and the host still uses function calling to invoke them. (4) Use plain function calling for one app and a couple of tools. (5) Reach for MCP when many clients need the same tools.
What is function calling? One tool wired into one app
Function calling is a request-level contract between your app and a model. You pass a list of tools in the API request, each described by a name, a description, and a JSON Schema for its parameters. The model reads that list, decides whether a tool fits the user's request, and returns the tool name plus arguments. Your code runs the function and sends the result back.
With raw function calling, the tool definitions live in your application code, and the schema travels in the API payload for that specific provider. The model never runs your function. It only proposes a call. You own the execution, the error handling, and the glue. Fine for a single app, but the definitions stay bound to that codebase and that provider's tool format.
What is MCP, and what problem does it solve?
MCP exists because every new data source used to need its own custom integration. Anthropic introduced the protocol in November 2024 to replace that fragmented pattern with a universal, open standard. The announcement names the core pain directly: every new data source requires its own custom implementation, which makes connected systems hard to scale.
Here is the math that explains the whole protocol. With M AI apps and N tools, naive integration pushes you toward M times N bespoke connectors. Add a new app and you re-wire every tool. Add a new tool and you re-wire every app. A shared protocol collapses that into M plus N: each app implements the client side once, each tool implements the server side once, and they interoperate. The official docs use a USB-C analogy for this: one standardized port instead of a drawer of adapters.
MCP architecture: host, client, and server explained
MCP follows a client-server architecture with three named roles. The host is the AI application that coordinates everything, such as Claude Desktop, VS Code, or Cursor. The client is a connector object the host creates, one per server, that maintains a single connection. The server is the program that exposes tools, resources, and prompts.
The whole protocol in one line: M×N bespoke connectors collapse into M+N. Each app implements the client side once, each tool implements the server side once, and they interoperate.
What each role does
- Host: the AI app the user talks to. It owns the language model, manages clients, and decides how to use the context servers provide.
- Client: a per-server connector inside the host. It runs the handshake, lists what a server offers, and routes calls to it.
- Server: a standalone program exposing capabilities. It can run locally on your machine or remotely behind HTTP, and the same server can serve one client or many.
The MCP spec is precise about what servers expose. Servers offer three primitives: tools (executable functions the model can invoke), resources (data sources that supply context, like file contents or records), and prompts (reusable templates). Clients can also expose primitives back, including sampling, which lets a server ask the host's model for a completion without bundling its own model SDK. That separation is what keeps a server model-independent.
One concrete example: write the server once, plug it into Claude and VS Code
Reference and official servers make the difference concrete. The filesystem server, a reference implementation maintained in the official servers repository, exposes tools for reading and writing files on your machine and runs locally over the stdio transport. GitHub's own MCP server exposes tools for issues, pull requests, and code search, and offers a remote version over HTTP. Both are servers you point a host at, rather than functions you embed in one app.
Connect the filesystem server to Claude Desktop and it works. Point VS Code at the same server and it works there too, with no code changes to the server. With raw function calling, you would write the file-read function once for the Claude app, again for the VS Code extension, and adapt the schema for each provider's tool format. The server-once model is the entire reason MCP exists.
How MCP works under the hood: JSON-RPC and transports
MCP messages use JSON-RPC 2.0. That is the data layer: a defined message format for requests, responses, and notifications between client and server. A client calls tools/list to discover what a server offers, then tools/call to run one with arguments. Because the message shape is standardized, any compliant host and any compliant server can talk, regardless of who wrote them.
MCP separates that data layer from the transport layer. Two transports are defined. Stdio uses standard input and output streams for local processes on the same machine, with no network hop. Streamable HTTP uses HTTP POST plus optional Server-Sent Events for remote servers, and it carries standard authentication such as bearer tokens, with OAuth recommended for obtaining them. The same JSON-RPC messages ride either transport, so a tool written for local stdio can move to remote HTTP without changing its logic.
Discovery is the part function calling lacks. In raw function calling you hardcode the tool list into each request. In MCP, the client asks the server what it offers at runtime, and the server can push a notification when its tool list changes. The host refreshes and the model gains the new capability mid-conversation. Tool availability becomes dynamic instead of baked into your app at build time.
| Dimension | Function calling | MCP |
|---|---|---|
| What it is | A model-to-tool contract inside one app | An open client-server protocol across apps |
| Where tool defs live | In your app code, sent per API request | In a standalone server, discovered at runtime |
| Reuse across apps | Re-wire per app and per provider format | Write the server once, any host can use it |
| Discovery | Hardcoded tool list in each request | tools/list plus change notifications |
| Wire format | Provider-specific JSON in the API payload | JSON-RPC 2.0 over stdio or HTTP |
| Maintenance burden | One integration per app and provider | One server, reused across hosts |
Decision rule in 30 seconds: one app plus a fixed handful of private tools points to function calling. The same tools needed across two or more hosts, or a tool list that changes at runtime, points to MCP. Already on function calling and now need reuse: keep the function bodies, wrap them in an MCP server.
When to use function calling instead of MCP
Use plain function calling when one app needs a handful of tools and you control both ends. If a single backend calls a single model with three internal functions, MCP adds a server, a transport, and a handshake you do not need. The function-calling loop is well documented and ships in every major SDK.
- Your tools are private to one application and unlikely to be reused elsewhere.
- You have a small, stable set of functions that rarely changes at runtime.
- You are prototyping and want the fewest moving parts.
- You are committed to one model provider and its tool format is fine for you.
Good news if you picked function calling first: the migration is small. Wrap your existing functions in an MCP server: the bodies stay, you add a thin protocol layer in front.
When to use MCP instead of function calling
Reach for MCP when the same capabilities need to reach several AI apps, or several apps need the same capabilities. The protocol already has broad client support: Claude, ChatGPT, VS Code, and Cursor all act as MCP hosts. Build a server once and it plugs into all of them, one integration instead of one per app.
- Multiple internal apps or agents need the same set of tools.
- You want runtime discovery so tools can appear and disappear without redeploying clients.
- You need the same tool to run locally over stdio in development and remotely over HTTP in production.
- You want to consume third-party servers from an existing ecosystem instead of writing every connector yourself.
What MCP does not do
Where MemX fits: MCP moves the call; MemX supplies the recalled knowledge the call might need. MCP standardizes how an app reaches a tool, but it does not give a model your personal context. MemX (memx.app) is an external memory layer that captures your documents, screenshots, photos, voice notes, and forwarded messages, indexes them for retrieval, and lets you ask any model questions against that context. They solve different halves of the problem.
On auth, MCP defers to the transport rather than inventing its own identity layer. The HTTP transport supports standard authentication methods, including bearer tokens and API keys, and the docs recommend OAuth to obtain those tokens. MCP carries credentials over established mechanisms; it does not replace your auth provider. Treat it as a connection standard, not a security product or a memory store.
Staying current: write to the architecture, not a feature
The protocol versions over time, so anchor your understanding to the stable architecture rather than any single release. Initialize messages carry a protocolVersion field, and the spec evolves through dated revisions. The durable concepts have held since launch: host, client, server; tools, resources, prompts; JSON-RPC over a swappable transport. Build against those and version bumps stay manageable.
Where MemX fits: MCP standardizes how an app reaches a tool. It does not give a model your personal context. MemX (memx.app) is an external memory layer that captures your documents, screenshots, photos, voice notes, and forwarded messages, indexes them for retrieval, and lets you ask any model questions against that context. MCP moves the call; MemX supplies the recalled knowledge the call might need. They solve different halves of the problem.
Key takeaway: they stack, they don't compete. Function calling connects a model to a tool inside one app. MCP standardizes that connection so a tool written once works across many apps and models. An MCP server exposes the tool; the host still runs a function-calling loop to invoke it. Choose plain function calling for one app, and MCP when reuse across clients is the goal.
01Does MCP replace function calling?
No. They stack. If you use MCP, the host still uses function calling internally to let the model choose and invoke a tool. If you have one app with a few private tools, plain function calling alone is enough and MCP adds overhead you do not need.
02Is MCP just function calling with extra steps?
No. MCP wraps the pattern rather than replacing it. Function calling is how a model proposes a tool invocation inside one app. MCP is a client-server protocol that standardizes how tools are exposed and discovered across many apps. An MCP server still gets invoked through a function-calling-style loop.
03When should I use MCP vs function calling?
Use plain function calling when one app needs a fixed handful of private tools and you control both ends. Use MCP when the same tools must reach two or more hosts, or when the tool list changes at runtime. If you already built function calling, wrap those functions in an MCP server.
04Is MCP only for AI agents?
No. MCP is a connection protocol, not an agent framework. Any MCP host, such as Claude Desktop, VS Code, or Cursor, can connect to a server and call its tools in a normal chat. You do not need a multi-step autonomous agent to benefit from it.
05What protocol does MCP use under the hood?
MCP uses JSON-RPC 2.0 for its message format. Those messages travel over one of two transports: stdio for local processes on the same machine, or Streamable HTTP for remote servers. The same JSON-RPC messages work on either transport, so a tool can move from local to remote without logic changes.
