APPLIED AI

What is MCP? A practical guide for business

29 September 2026Marcos Serrano

An AI assistant can write, summarize and reason well, but it knows nothing about your company. It cannot see your CRM, does not know the status of an order in your ERP and cannot look at the billing database. For it to be useful day to day, someone has to connect it to those systems.

Until recently that connection was built by hand, one integration at a time, and separately for every AI tool. It is bespoke work that breaks when the model, the API or the vendor changes. MCP exists to end that glue code: a standard way for AI to talk to your systems. Here is what it is, what you can do with it inside a company, and where it goes wrong when it is rolled out in a hurry.

What is MCP (Model Context Protocol)

MCP stands for Model Context Protocol, an open standard that defines how an AI application connects to external data sources and tools. Anthropic introduced it as an open-source project in November 2024, and it has since been adopted by OpenAI, Google, Microsoft and many software vendors. In December 2025 it moved to the Agentic AI Foundation under the Linux Foundation, so it no longer depends on a single company. The specification lives at modelcontextprotocol.io.

When someone asks what “an MCP” is, they almost always mean an MCP server: the specific connector that exposes one system, as in “the GitHub MCP” or “the MCP for our CRM”. The protocol is the rule; each server is a piece that follows it.

The usual analogy is USB-C for AI: one connector instead of a different cable for every pair of devices. It fits the problem it solves. With 3 AI apps and 3 internal systems, no standard means building 9 integrations. With MCP it is 3 + 3: each system gets its MCP server and each app its MCP client. Since the major assistants already ship with the client built in, in practice you only build the 3 servers.

The N×M problem: without a standard, every AI app needs its own connection to every system.

How it works: host, client and server

The architecture is client–server, with three pieces:

Host: the application the person works in. It can be Claude, ChatGPT, an editor such as Cursor, or an internal app of yours.
MCP client: the part of the host that talks to the servers. The host opens one client for each server it connects to.
MCP server: a small program that exposes one of your systems (CRM, ERP, database, documentation) in the format the protocol understands. This is the piece you build, or that we build for you.

The host talks to several MCP servers; each server sits on top of the API or database of one of your systems.

Each MCP server offers three kinds of capabilities. They are worth telling apart because they do not carry the same risk: reading a document is not the same as running an action.

Tools: actions the model can ask to run, such as “create a task” or “look up a customer’s orders”.
Resources: data and context that can be read, such as a document, a record or the result of a query.
Prompts: reusable instruction templates, for example “prepare the weekly account summary”.

There are two ways to connect. stdio is for local servers running on the same machine as the host. Streamable HTTP is for remote servers, and for those the specification defines authorization based on OAuth 2.1. In a company almost everything interesting is remote and shared, so authentication is not a detail.

What happens inside when someone asks their assistant something and it queries a real system.

What MCP is used for in a company

These are the uses we run into most, all built on systems you already have:

Sales querying the CRM in plain language. “Which opportunities this quarter have had no activity for two weeks?” With an MCP server on top of Zoho CRM, the salesperson asks their assistant and, if they want, has it create the follow-up task. No opening the CRM, no building filters.
Support with full context. The agent reads the ticket and, in the same conversation, checks order status and invoices in the ERP. The answer no longer depends on switching tabs four times.
Finance and operations querying data. A read-only server over the database lets people ask about pending payments or stock and get an answer with its source. The model cannot change anything, because the server only exposes bounded queries.
Internal knowledge search. Manuals, contracts, procedures and technical docs available as resources, with the permissions of the person asking.
Developer tooling. Technical teams connect their coding assistant to GitHub, Sentry or internal docs to investigate a failure with real data.
Operations that trigger workflows. From the assistant you launch an existing process, such as generating a report or reprocessing a batch of payments, with confirmation first.

Notice the pattern: in every case the heavy lifting (business rules, validation, permissions) already lives in your system. MCP only lets the AI reach it in a controlled way. If the process side interests you, we cover it in AI process automation.

MCP vs API: what is the difference

It is the question we get most when we explain MCP, and fairly so: both connect software to software. The difference is who the client is.

An API is built for programs. A developer reads the docs, decides which endpoint to call and with which parameters, and hard-codes it. If tomorrow you want to use that API from another tool, you write the integration again.

An MCP server is built for AI models. The MCP client asks the server which tools it offers, and each tool comes with a plain-language description and a parameter schema the model understands. The model decides, conversation by conversation, which tool to use. And because the protocol is the same for everyone, that server works with any compatible assistant.

	API	MCP
Who uses it	A program written by a developer	An AI model, through an MCP client
How it is discovered	By reading the docs	The client asks the server what it offers
Who decides what to call	The code, fixed in advance	The model, based on the request
Reuse	One integration per tool	One server for any compatible host

The practical takeaway: it is not MCP or API, it is MCP on top of the API. The MCP server translates the model’s requests into calls to your API, with the permissions and limits you set. That is why, when a client asks us for “an MCP for our ERP”, the first thing we check is whether that ERP has a decent API.

Benefits of MCP for a business

Build once, reuse everywhere. An MCP server on your CRM can be used by Claude, ChatGPT or your own app. If you switch AI vendor tomorrow, the connector is still there and you are not tied to a single vendor.
Control over what is exposed. You decide which tools and data exist, with which permissions and which logging. The model can only do what the server offers.
Faster integration. The protocol already handles capability discovery, call format and errors, so the time goes to what matters: what to expose and under which rules.
You decide which data leaves. The server runs in your infrastructure and returns to the model only the minimum needed to answer. Whatever it does not expose, the AI vendor never sees. If that worries you, we have another article on GDPR and data with language models.

Risks and mistakes to avoid

MCP is powerful precisely because it gives AI hands. That is what needs care. The mistakes we see most:

Exposing write tools without confirmation. A model can misread a request. Creating, changing or deleting should ask for human confirmation, and anything irreversible is better left unexposed.
Over-broad permissions. Connecting the server with an admin token “so it works” is the most expensive shortcut. Each server should use least-privilege credentials, ideally the user’s own.
Prompt injection. Content returned by a tool or resource, such as an email, a record or a ticket, can include text designed to manipulate the model. Treat anything from outside as data, not orders, and limit what the model can do after reading it.
Dumping huge responses into context. Returning 5,000 rows does not make the model smarter: it makes it slower, costlier and less accurate. Tools should filter, paginate and summarize.
No logging. If you do not know who asked for what and what ran, you can neither audit nor debug. Every call should land in a log.
Treating MCP as a replacement for a proper API. MCP sits on top of your API, it does not replace it. If the system has no reliable API, with validation and permissions, the MCP server inherits that problem.

How we help you roll it out

We work with a short, verifiable method, designed so you see results with a real team before committing further:

Discovery. We review which systems you have and which questions or tasks would genuinely save time. We prioritize one or two cases, not ten.
Design. We define which tools and resources are exposed, which are read-only and which need confirmation, and what permissions each profile has.
Build. We build the MCP server on your existing APIs or, if there is no reliable API, create it first. That is common when the system is an older ERP.
Security and operations. Authentication, audit logging and usage limits from day one, not as a later patch.
Pilot. One team uses it with real data for a few weeks and we measure whether it saves them work.
Iterate. We adjust what does not work and extend to more systems and teams only if the pilot justifies it.

The result: your team can ask their AI assistant things about your systems under the rules and permissions you decided, and any compatible tool can reuse that foundation.

Wrapping up

MCP is not a fad, it is the standard cable that was missing. But a badly designed connector gives AI more access than it should have. Designing that connector properly is exactly what we do in applied AI. Tell us which systems you have via contact and we will tell you whether it pays off. And if your starting point is APIs, first read how to connect systems with a custom API.