MCP vs function calling: not a rivalry

Function calling is a model capability: you describe some functions in the request, and the model, when appropriate, returns a structured call — the function name and typed arguments — which your code then executes and feeds back. It’s the mechanism that turns a text model into an agent. MCP (Model Context Protocol) is an open standard: it defines how an agent (the client) connects to MCP servers that expose tools, resources and prompts, so any compliant agent can plug into any compliant server without custom glue.

It's tempting to think MCP is just "function calling, but standardized" — send a list of tool schemas, get a structured call back. That undersells it. A hand-rolled function-calling integration typically hard-codes a fixed list of tools into your app at build time: you write the schemas, you write the handlers, and adding a new tool means shipping a code change. MCP instead defines a live discovery protocol — an agent connects to a server and asks "what do you offer?" at connection time, so a server can add, remove, or change its tools without every client needing a code update. The agent adapts to whatever the server currently exposes.

MCP also standardizes two things plain function calling has no opinion on. Resources are addressable pieces of context a server can expose (a file, a database record, a URL) that the client can read into the conversation without that read itself being a "tool call" the model has to decide to make — useful for context an agent should just have, not context it has to think to ask for. Prompts are reusable, server-defined prompt templates a client can surface to a user (think "slash commands" a server ships alongside its tools) — a layer of UX convention plain function calling never touches, since function calling only defines how a MODEL requests an action, not how a HUMAN using the client interacts with a server's capabilities.

Say your coding assistant needs to search your company's internal wiki. With plain function calling, you write a search_wiki(query: string) function schema, implement the handler (call your wiki's search API, format results), and wire it into your app's system prompt alongside whatever other tools that specific app needs. It's yours: you control the schema exactly, you own the handler code, and nothing changes until you change it. But it only works in this one app — if your team also wants wiki search available in a separate internal Slack bot, you write the integration again.

With MCP, your team instead builds one wiki-search MCP server once, exposing a search_wiki tool (and maybe a wiki_page resource for direct page access) through the standard protocol. The coding assistant connects to it as an MCP client and gets the tool automatically via discovery — no schema hand-written into that app's code. The same server now also plugs into the Slack bot, into a CLI tool, into any other MCP-compliant agent your team builds later, with zero additional integration work per client. The cost is real too: you're now running and maintaining a server process, and every client that connects is trusting whatever that server currently exposes.