A plain explanation for anyone who keeps being asked to choose between three things that were never competing.
Every few months a new acronym shows up in the AI world, and the same question follows it around the room: which one should we use?
Lately the question has been about three things at once. REST APIs, function calling, and something called MCP. They get lined up side by side like three phones on a shelf, as if you were meant to pick one and take it home.
That framing is where the confusion starts. These three were never competing. They sit on top of one another, and once you can see the stack, most of the decision makes itself.
Asking which one to use is a bit like asking whether to use the road, the car, or the GPS.
REST is the oldest and the most familiar. It is how one program asks another to do something over the web, with endpoints, methods and parameters. It was built for programmers. Real services, like a payment provider or your ticket system, live at this level.
Function calling is how a language model asks for something to be done. The model never runs anything itself. It writes out a structured request, such as "look up this order with this number", and your own code decides whether to carry it out. The model proposes, and your application acts.
MCP, the Model Context Protocol, is an open standard introduced in late 2024 so that AI applications can discover and use tools in a common way. A server describes the tools it offers in terms a model can understand, and any app that speaks MCP can use them. Very often an MCP server is simply a friendly wrapper around a REST API that already exists.
Pick a scenario and watch which layers light up. Notice how often the answer is only one.
The model writes a structured request. Your code decides whether to run it.
A common way for apps and agents to find and use many tools without custom wiring for each.
The services your systems already expose: payments, tickets, calendars, databases.
Picture a handful of AI apps and a handful of systems they all want to reach. Without a shared standard, every app needs its own hand-built connection to every system. Add one more app and you write several new integrations. Add one more system and you write several more.
With a shared standard, each system offers one MCP server, and each app learns to speak MCP once. The connections stop multiplying and start adding up. Move the sliders and see how quickly the two numbers drift apart.
A simplified model, but it shows why a common standard matters once there are many apps and many systems.
REST is not the thing that was missing. What REST does not tell a model is which tools exist and when to reach for them. MCP adds that layer of discovery and description, and that is why it appeared at the same time as agents.
If there is no AI anywhere in the path, REST on its own is the whole answer, and nothing else is needed. If you have one application with a few tools, function calling straight into your existing REST endpoints is simple and usually enough.
Once you have many tools, many apps, or a wish to reuse tools other people already built, that is when MCP starts to pay for itself. A single agent workflow can easily use all three at once. The model asks through function calling, the request travels through an MCP server, and that server calls a REST API underneath.
Start with the simplest layer that works, and climb one level only when a real problem asks you to.
The easier it becomes for an agent to find and use tools, the more it matters which tools it is allowed to use, and with what access. Tools from third parties are also a new place for things to go wrong. The text a tool returns can contain hidden instructions meant to steer the agent, which is called prompt injection. Treat what comes back from a tool as untrusted data, never as a command.
MCP is still evolving quickly. Before you build anything serious on it, read the current official documentation, because the details move faster than any article can.
See how this connects to testing, and how to try agents safely in a QA team.
Written by Aditya Mirza Bahari, 2026. MCP details change quickly, so check the official documentation before building on it.