Two arguments come up in nearly every MCP conversation. One says MCP is a new kind of API, so the existing APIs can be retired or ignored. The other says the model can already call functions, so MCP adds nothing. Both arguments treat three different things as competitors for the same job.
They are not. An API, function calling and MCP sit at different layers of the same stack. Each does one job well and leaves something important out. Mixing them up leads to two expensive mistakes: rebuilding integrations that already worked, and assuming a layer provides protection that only a lower layer can.
This part separates the three, using the same fictional insurer as Part 1.
Kwelanga Insurance is fictional, and its systems and figures are illustrative. By the time the architecture review met, the platform team had already heard both arguments inside the company. The claims platform owner wanted to know whether her REST API was now obsolete. A developer wanted to skip MCP and hard-code function definitions into Kwelanga Assist. The review's job was to say what each layer was for.
Layer one: the API
An application programming interface exposes a capability of an application to other code. Kwelanga's claims platform has a REST API with endpoints to fetch a claim, list notes, add a note and change a claim's status. The broker portal calls it. The nightly finance export calls it.
The API is where the real rules live, or should. It authenticates the caller, checks that the caller may touch this claim, validates the input and writes the record. If the API checks nothing, nothing above it can make it safe; it can only add a second gate in front of an open door.
What an API does not provide is anything a language model can use without help. Its documentation is written for developers. Its endpoint names, such as PATCH /v2/claims/{id}/status, describe mechanics, not tasks. A model given the raw OpenAPI document for 140 endpoints will try to use them, and the results are rarely what anyone intended.
Layer two: function or tool calling
Function calling, which most model providers now call tool use, lets a model choose a declared operation and fill in its arguments. The application tells the model, in a structured definition, "here are the operations you may request, with these parameters". The model returns a request to call one. The application's code decides whether to run it.
That last sentence matters. In tool calling, the model proposes and the application disposes. The model never touches the claims API directly. Kwelanga's code receives "call get_claim_summary with claim number KW-2026-118734", checks it, calls the API and hands the result back.
What tool calling does not provide is a shared standard across applications. Each AI application declares its tools in its own code, in its own format. If Kwelanga Assist, the broker portal's bot and a developer's coding agent all need claim summaries, each team writes and maintains its own definition and its own integration code. Three applications, three systems: nine integrations to keep in step.
Layer three: MCP
MCP standardises the layer between the AI application and the capability. A system publishes an MCP server once; any compliant application can discover what it offers and call it in the same way. The current specification, version 2026-07-28 as checked on 14 October 2026, defines how tools are listed (tools/list), how they are called (tools/call), how results and errors come back, and how resources and prompts are offered alongside tools.
So MCP does not replace tool calling. Inside the host, the model still selects a tool and the client still makes the call. What MCP replaces is the bespoke wiring: instead of every host carrying its own definition of every tool, the host asks the server what it offers.
What MCP does not provide is enterprise authorisation and safe business meaning. It can carry a token. It can let a server return a smaller tool list to a caller with fewer scopes. It cannot know that a handler in the motor portfolio should not see a commercial claim, or that adding a note to a claim in litigation needs a supervisor's sign-off. Those rules belong in the server's code and in the system of record beneath it.
The same capability, three ways
The review used one capability to make the layers concrete: "summarise this claim for a handler".
| Layer | What Kwelanga builds | Where the rule "only assigned handlers" lives |
|---|---|---|
| API only | A GET /claims/{id}/summary endpoint | In the claims platform, if it was built |
| Tool calling | A tool definition in each assistant, calling the endpoint | Still in the claims platform; each assistant can add its own check |
| MCP | One claims server exposing get_claim_summary | Still in the claims platform; the MCP server can add its own check once |
In every row, the rule ends up in the same place. MCP changes how many integrations exist. It does not move the place where authority is decided.
Where each layer is the right answer
The useful question is not "which layer wins?" but "which layer does this situation need?"
Use the API directly when the consumer is ordinary software with a fixed purpose. Kwelanga's finance export does not need a model to choose anything. Putting MCP in front of it adds a hop and a new failure point for no benefit.
Use tool calling inside one application when there is one AI application, a small number of tools and no expectation that other applications will reuse them. A single-purpose triage bot with three tools does not need a protocol.
Use MCP when several AI applications need the same capabilities, when you want people to be able to use those capabilities from tools they already work in, or when you expect the set of consuming applications to grow. Kwelanga's case fits: the staff assistant, a developer agent and later perhaps the broker portal all need policy lookup.
Never skip the API's own checks because a layer above it does checking. Defence in depth is not duplication. A misconfigured MCP server, or a developer calling the API directly, should still hit a wall.
The mistake in each direction
The claims platform owner's worry, that MCP makes her API obsolete, had it backwards. The MCP server calls her API. If anything, her API becomes more important, because it is now the last line of defence behind several AI applications instead of one portal.
The developer's shortcut, hard-coding tool definitions, was not wrong for a prototype. It becomes wrong when the second and third applications arrive and each team copies the definitions, edits them slightly and stops updating them. Six months later nobody knows which assistant uses which version of "add file note", and a change to the claims API breaks two of them silently.
The review's conclusion fitted on one slide. APIs stay and get stricter. MCP servers sit in front of a deliberately small set of them. Each MCP server calls its API with the user's delegated identity, not a shared account. And nothing in the AI layer is allowed to be the only place a rule is enforced.
Key points
Three layers, three jobs. An API exposes capability to code, tool calling lets a model choose a declared operation, and MCP standardises discovery and calls across applications.
MCP does not replace tool calling. Inside the host, the model still selects and the application still executes. MCP replaces bespoke wiring.
Authority lives below all three. In every design, the rule about who may do what belongs in the server code and the system of record.
Pick the layer the situation needs. Fixed-purpose software uses the API; one AI app with a few tools can use tool calling; many AI apps sharing capabilities is where MCP pays off.
APIs get more important, not less. They become the last line of defence behind several AI applications.
Next: Part 3, MCP is a context boundary, not a tool catalogue. All parts are on the series page. For a plain-language introduction to tools themselves, see Tools: how AI agents actually do work.
How CloudNala can help
We help architecture teams decide which capabilities belong behind an MCP server, which should stay as plain APIs and which need their API-level controls strengthened before any AI application touches them. The output is a short integration map and a list of the rules that must live in the systems of record, so the AI layer is never the only thing standing between a user and a sensitive record.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book an MCP Security Review or write to us at consult@cloudnala.co.za