TL;DR
The Model Context Protocol (MCP) is an open standard that lets an AI assistant discover and call tools in your systems at runtime. A system is exposed once as an MCP server; every assistant that speaks the protocol can then use it. It is stewarded under the Linux Foundation and supported by every major model vendor. What it does not do is decide who may use which tool, with which arguments, and prove it afterwards. That is the layer IT has to add before saying yes.
What MCP is
An AI assistant on its own can read what you paste into it and write text back. It cannot look up a customer in your CRM, check an order, or open a ticket, because it has no way to reach those systems and no way to know what they offer.
MCP fixes that with a contract. A system publishes an MCP server that describes, in a standard format, the things an assistant may do with it: each one has a name, a plain-language description and a typed schema for its inputs. The assistant's MCP client connects, asks what is available, and calls those things by name. The model decides which call to make next from the description, the same way a person would read a menu.
Anthropic published the protocol in November 2024. It has since been adopted by OpenAI, Google, Microsoft and AWS, and its governance moved to the Linux Foundation's Agentic AI Foundation, of which Palma is a member. The practical consequence is that a system exposed over MCP is reachable from ChatGPT, Claude, Copilot, Gemini and the coding agents alike, with no per-assistant work.
The three parts
Servers
A server wraps one system and exposes what an assistant may do with it. It offers tools (actions the assistant can take, such as "look up order"), resources (data it can read, such as a document) and prompts (reusable instructions). For most SaaS products a server already exists; for in-house systems, one is written once, usually as a thin layer over an existing API.
Clients
The client lives inside the assistant. When a person asks for something, the client presents the model with the tools available to it and executes the calls the model chooses. The person does not see any of this; they see their assistant answer a question it could not answer before.
The protocol
The wire format between the two. It defines how a client discovers what a server offers, how a call and its result are shaped, and how errors come back. Because it is the same for every server and every client, a server written for one assistant works with all of them.
What it looks like for one person
Someone in customer support gets a message about a delayed order. In their assistant (whichever one the company has chosen) they ask what happened. The assistant looks up the customer in the CRM, reads the order from fulfilment, checks the carrier's tracking and drafts a reply with the actual delivery date. If the case warrants a credit, the assistant proposes it, and a person approves it before it is issued.
Nothing about that sequence was scripted in advance. The assistant had four described tools and worked out which to use. That is the difference MCP makes: the work moves from "draft me a reply" to "sort this out", and the person stays in the loop for the step that matters.
Why it matters at enterprise scale
- One server per system, not one integration per assistant. With three assistants and twelve systems, per-client integration is thirty-six pieces of work. Over MCP it is twelve. The arithmetic is in MCP vs API.
- Adding a system is one step. Expose it once; every assistant can use it.
- Maintenance shrinks the same way. When a system changes its API, one server changes. The assistants notice nothing.
- No lock-in to a vendor's assistant. The protocol is open. Swap assistants and the servers stay.
What MCP does not do
This is the part of most explainers that goes missing, and it is the part IT will ask about first.
The protocol defines how a tool is described and called, and how a client authenticates to a server; MCP has an authorisation specification for that. It does not decide which person may use which tool, on which records. An authorised client sees everything the server exposes to it. "Read a CRM record" and "read any CRM record, including the ones under legal hold" are the same tool. Issuing a refund and reading the refund policy are both just calls. Nothing in the protocol records who did what in a form an auditor will accept, and nothing attributes what it cost to the team that used it.
So a working MCP setup and an approvable one are different things. The approvable one has a layer above the protocol that answers the five questions IT actually asks:
- Who is allowed to use this tool at all?
- What exactly may they do with it, on which records?
- What happens when the assistant tries something risky?
- Where did the data go?
- Can you prove all of the above afterwards?
That is where Palma sits. Each person gets one governed connector, assigned through the groups they already hold in the identity provider, carrying every tool and Skill they are entitled to into whichever assistant they use. Policies are evaluated on the actual arguments of a call. Calls that need a human are routed for approval. Every call is logged with who, what, when and why, and cost is attributed per team. The servers and the assistants do not change; what changes is that IT can say yes.
Where to start
- Pick one team and the two or three systems they actually use. Most of those systems will already have an MCP server.
- Connect the identity provider, so entitlement follows the groups you already maintain rather than a new list.
- Decide the policy for the handful of tools that write, not just read: which may run, which need approval.
- Let the second team inherit the same servers instead of building their own.
Further reading: MCP vs API for where plain APIs still win; The ROI of MCP for the business case; Why API gateways don't work for agents for the governance argument in full; and the platform page for what Palma does with all of it. If you would rather talk it through, book thirty minutes.
