Explain the problem that the Model Context Protocol (MCP) solves that provider native function calling (OpenAI functions, Anthropic tool_use) does not. What does 'transport layer' mean in this context?
Function calling re-binds every tool to each provider's API, so M models times N tools means M times N integrations. MCP standardises one protocol, turning that into M plus N.
Imagine every appliance you own needed a different shaped plug for each brand of wall socket. A toaster plug for one house, a totally different toaster plug for the next. With three brands of socket and ten appliances, you would carry thirty plugs. That is the world of provider-specific tool integrations: each model speaks its own dialect, so you rewire every tool for every model. Now imagine a universal socket standard. Every appliance ships one plug, every wall accepts it, and you stop caring which brand built the wall. That standard is what MCP is for AI tools. The model is the appliance, the tool is the socket, and the protocol is the agreed plug shape. Build the tool once, and any model that speaks the protocol can use it without rewiring.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
The Model Context Protocol (MCP) is an open standard for connecting language models to external tools, data, and prompts. It was introduced by Anthropic in late 2024 and has since been adopted across the ecosystem, including by OpenAI and a growing registry of community servers. To understand why it exists, you first have to feel the pain it removes.
That pain is integration math. Provider-native function calling ties every tool definition to one model vendor's API shape. The schema you hand OpenAI, the way you parse its tool call, and the loop you write to feed results back all assume that vendor. Anthropic's tool use is conceptually identical but differs in the JSON details. So if you support several models and several tools, the number of integrations you maintain grows as the product of the two, not the sum.
MCP replaces that product with a sum by inserting one shared contract between any model and any tool. A tool, published once, becomes reachable by any model that speaks the protocol. This document walks through the problem, why MCP sits above function calling rather than competing with it, the protocol's three primitives, its transport layer, and the tradeoffs a senior engineer should weigh before adopting it.
The M times N integration explosion
Function calling is excellent at one job: letting a model emit a structured request to run a named tool with typed arguments. The catch is that the schema and the request format belong to the provider. OpenAI describes tools one way. Anthropic describes them in a similar but not identical way. Other providers differ again.
Now scale it. Suppose you maintain N tools and want them to work with M model providers. With provider-specific definitions you write and test up to M times N integrations, because each tool must be re-expressed for each model's format. Add a model and you redo N integrations. Add a tool and you redo M. Switching your default model mid-project means rewiring everything.
The core MCP claim is that this product should be a sum:
You publish each tool once as an MCP server, giving N servers. Each model ships one MCP client, giving M clients. Any compliant client can talk to any compliant server, so the two sides compose rather than multiply. This is the same shape of win that USB-C brought to device charging, and it is the single most important thing to say in an interview.
The payoff is not only fewer integrations to write today. It is decoupling over time. A tool team and a model team can move independently: the tool team ships and versions a server without knowing which models consume it, and the model team adopts a new provider without touching any tool. That separation of ownership is exactly what lets an ecosystem of third-party servers exist at all, because a vendor can publish one server and reach every compliant host.
Situations where this technique stops working.
2–4 min · Everything important, quickly.
Real products, models, and research that use this idea.
- Anthropic ships MCP servers for the Claude desktop app and Claude Code, letting Claude Opus 4.7 reach local files, GitHub, and Postgres over the same protocol.
- The reference MCP server registry includes stdio servers for filesystem, Git, Slack, and Google Drive that any compliant client can load without provider-specific glue.
What an interviewer would ask next. Try answering before peeking at the approach.
QHow does an MCP client discover what tools, resources, and prompts a server offers at runtime?
Walk through the initialise handshake and the list endpoints. The client connects over the transport, negotiates capabilities, then calls the list methods so tool schemas are fetched dynamically rather than hardcoded into the client.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Saying MCP replaces function calling. It does not. The model still emits a tool call through native function calling. MCP standardises how tools are discovered and reached, not how the model decides to call them.
60 second bullets to scan on the way to the call.
State the M times N integration explosion and how a standard protocol turns it into M plus N.
Explain why provider native function calling forces re-registration when you switch models.
Primary sources. Browse if you want the original framing.
Same topic, related formats. Practice these next.