A year ago, connecting an AI assistant to a company system meant a bespoke integration. Today a developer can often install an MCP server, point an assistant at it and watch the assistant list the system's capabilities and start using them within the hour. That speed is real, and it is why the Model Context Protocol has gone from a niche specification to a line item in enterprise roadmaps.
The speed also creates a misunderstanding. Because the assistant can reach the claims system, people start to talk as if the assistant is now allowed to reach the claims system, for any user, for any claim, for any purpose. The protocol did not make that decision. Nobody did.
This six-part series is about the gap between those two statements. MCP standardises how an AI application discovers and invokes capabilities. It does not establish trust, business authority, data classification, least privilege, safe tool semantics or operational ownership. Those still have to be designed, and the rest of the series shows how.
In plain language:
MCP is a standard plug. It tells you how the appliance and the socket fit together. It does not tell you whether the appliance is safe, who may switch it on, or what happens if it shorts.
The universal adapter, used carefully
The usual analogy for MCP is a universal travel adapter. Before it, every AI application needed its own cable for every system. After it, a system publishes one standard socket and any compliant application can plug in.
That analogy is accurate about one thing and silent about three others. It is accurate that the shape of the connection becomes common. It says nothing about the voltage on the other side, about who is holding the appliance, or about whether the appliance should be plugged in at this moment. An adapter makes a hairdryer fit a foreign socket. It does not make it safe to use in the bath.
The same is true here. The protocol defines how capabilities are described, listed and called. Whether a particular person, working through a particular assistant, should be able to perform a particular action on a particular record is a business and security decision that sits entirely outside the plug.
Kwelanga's first week with MCP
Kwelanga Insurance is fictional, and its systems and figures are illustrative. Kwelanga is a short-term insurer headquartered in Gqeberha, with about 600 staff, roughly 140 of them claims handlers working motor, property and commercial portfolios. It runs a claims platform, a policy administration system and a broker portal, all maintained by a twelve-person platform team.
Kwelanga wanted to give staff an internal assistant, Kwelanga Assist, that could answer questions such as "what excess applies on this policy?" or "summarise the last three notes on this claim" without staff switching between screens. A developer on the platform team built a proof of concept in four days. It had three MCP servers:
- a claims server that could read claim summaries and add a file note to a claim;
- a policy server that could look up a policy by number and return its cover and excesses;
- an operations server that could restart a stuck queue worker on the claims platform.
The demo was impressive. The head of claims asked when it could go live. The security architect asked a different question: "When a handler asks for a claim summary, whose permissions does the claims server use?" The answer was a shared service account with read access to every claim in the company. The demo worked because it ignored the question the business would have to answer first.
What MCP actually standardises
It helps to be precise, because MCP is now specific enough to be checked. The current specification is version 2026-07-28, published at modelcontextprotocol.io and checked on 14 October 2026. In its own terms:
- Hosts are the AI applications people use. Kwelanga Assist is a host.
- Clients are the connectors inside a host, one per server.
- Servers expose capabilities. They offer three kinds: tools the model can call, resources that provide context and data, and prompts that offer templated workflows.
- Messages use JSON-RPC 2.0, and there are two standard transports: stdio for a server launched as a local process, and Streamable HTTP for a remote server.
- For HTTP servers, there is an authorization framework based on OAuth 2.1, in which the MCP server acts as an OAuth resource server.
The 2026-07-28 revision also made a significant change: the protocol is now stateless. Every request carries its own protocol version and client capabilities, and there are no protocol-level sessions. A server that needs to remember something across calls, such as a draft or a basket, has to hand back an explicit identifier and check, on every call, that the caller is entitled to use it. That one change matters a great deal for security reviews, and Part 5 returns to it.
The governance of the protocol has changed too. Anthropic created MCP and donated it in December 2025 to the Agentic AI Foundation, a fund under the Linux Foundation, so it is no longer a single vendor's specification.
What the specification itself says it does not do
The most useful sentence in the MCP specification is an admission. It says that MCP "enables powerful capabilities through arbitrary data access and code execution paths", and that while the protocol "cannot enforce these security principles at the protocol level", implementers should build consent and authorisation flows, document security implications and implement appropriate access controls.
It goes further on tools. Tools "represent arbitrary code execution and must be treated with appropriate caution", hosts must obtain explicit user consent before invoking any tool, and descriptions of tool behaviour, including the annotations that say whether a tool is read-only or destructive, "should be considered untrusted, unless obtained from a trusted server".
Read plainly, the specification is telling you what this series is about: the protocol is the plug, and the safety is your job.
Three things people assume MCP gives them
"MCP handles security." It defines how an HTTP client gets and presents an access token, and it forbids a server from accepting tokens that were not issued for it. It does not decide what the token holder may do inside the claims platform. That decision lives in the claims platform, or in the MCP server's own code, or nowhere.
"If the server lists a tool, the agent may use it." A tool list is a menu, not a permission slip. The current specification allows a server to return a different tool list depending on the authorisation presented, which is useful, but only if someone designed the scopes that make the lists differ.
"The tool description tells us what the tool does." A description is text written by whoever operates the server. A model reads it and acts on it. If the server is not yours, or its description changed last week, the description is an input to be checked, not documentation to be believed. Part 3 explains why that makes the description part of the attack surface.
What Kwelanga decided
Kwelanga did not cancel the project. It narrowed the first release to what it could defend.
- Policy lookup went first. Policy cover and excesses are business information that any claims handler already sees. The policy server became read-only, and it uses the handler's own identity rather than a shared account.
- Claims reading came second, with a condition. The claims server would only return a claim if the handler is assigned to it, or to its portfolio, checked by the claims platform itself on every call.
- Writing file notes waited. Adding a note changes the legal record of a claim, so it needs confirmation and an audit trail designed first. Part 4 covers how that tool was redesigned.
- The operations server was removed from the staff assistant entirely. Restarting a queue worker is a production change. It belongs with on-call engineers, behind change control, not in a claims handler's chat window.
None of these decisions involved the protocol. All of them involved identity, data sensitivity, consequence and ownership. That is the pattern for the rest of the series.
Why this matters in South Africa
South African organisations adopting MCP tend to share two constraints. First, the systems an assistant most wants to reach, such as claims, policy, HR, billing and case management, are full of personal information that POPIA requires to be processed for a defined purpose and protected by reasonable security safeguards. An assistant that can read every claim because its connector used a service account is a POPIA conversation waiting to happen, regardless of how good the demo was. This is general information, not legal advice; take your privacy officer's view on your own case.
Second, most organisations here run lean platform teams. A twelve-person team cannot review a hundred community MCP servers, so it has to decide early which servers are allowed at all, who owns each one, and how a server is switched off when something goes wrong. Those are the subjects of Part 4 and Part 6.
Key points
MCP standardises connection. It defines how AI applications discover and call tools, resources and prompts, over JSON-RPC, with an OAuth-based framework for HTTP servers.
It does not establish trust. Whether a person, through an assistant, may perform an action on a record is still your decision to design and enforce.
The specification says so itself. Tools are treated as arbitrary code execution, and tool descriptions and annotations are untrusted unless the server is trusted.
A working demo proves the plug fits. It proves nothing about identity, data sensitivity, consequence or ownership.
Start with what you can defend. Read-only, low-sensitivity, user-identity tools first; side effects and operations later, or never.
Next: Part 2, API, function calling and MCP are different layers. All parts are on the series page. For how MCP relates to A2A and AP2, see MCP, A2A and AP2 are not the same thing.
How CloudNala can help
We help teams move an MCP proof of concept to something they can defend: working out which capabilities should be exposed at all, which identity each call should carry, which tools need confirmation, and who owns each server after the demo. We start from the systems you actually want an assistant to reach and the people who will use it, so the conversation is about your data and your risks rather than about the protocol.
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