What MCP is and what it can actually do for your company
An AI can write you a flawless email and still have no idea how many units are left in your warehouse. It can reason, but it knows nothing about your company, because its knowledge froze the day its training ended.
For two years, connecting those models to a company's systems meant building a custom adapter for every combination. One connector so ChatGPT could talk to your ERP, another so Claude could talk to the same ERP, another for your CRM. And every time one of those tools changed its API, the whole thing broke.
MCP is the standard that ended that. Here is what it is exactly, how it works underneath, what can go wrong and, above all, when it makes sense for a mid-sized company and when it is shooting yourself in the foot.
1. The problem it solves
Imagine you want an AI to answer «how many size M jackets are left in the Valencia warehouse?». The model does not know and cannot know, because that figure lives in your database and changes by the hour.
The classic answer was to build a bridge. The problem shows up when you multiply. With three different models and five systems to connect, you end up maintaining fifteen bridges, each with its own authentication, its own format and its own way of breaking.
Before
One connector per pairing- Every model needs its own adapter to every system
- Three models and five systems means fifteen integrations
- One API changes and everything depending on it breaks
- Tools are hardcoded into the application
With MCP
One server per system- Each system exposes one server and that is it
- Three models and five systems means five servers
- The server absorbs changes without touching the agent
- The model discovers the tools when it connects
2. What it is and who controls it now
MCP stands for Model Context Protocol. Anthropic published it as an open standard in November 2024, and it defines a common way for an AI application to ask an external service «what can you do?», receive a list of capabilities and invoke them.
The detail that matters when deciding whether to bet on it
On 9 December 2025, Anthropic donated MCP to the Agentic AI Foundation, created inside the Linux Foundation. In the same move, Block contributed its `goose` framework and OpenAI contributed `AGENTS.md`. Top-tier members include Amazon Web Services, Google, Microsoft, Cloudflare and Bloomberg, alongside the three above.
This is not a press release without consequences. It means MCP stopped being one company's standard and moved to neutral governance, with its direct competitors sitting at the same table. For a small business wondering whether this will still exist in three years, that is the difference between betting on a proprietary format and betting on something the industry backs.
3. The three building blocks, and who decides each
An MCP server exposes three kinds of thing. The distinction almost nobody explains, and which is right there in the official documentation, is that a different party controls each one. Understanding it changes how you design the system.
| Block | What it is | Who decides to use it | Example in a company |
|---|---|---|---|
| Tools | Functions that do something and change a system's state | The model | Reserve stock, create a ticket, issue a shipping label |
| Resources | Read-only data, identified by an address | The application | Look up an order, read the catalogue, see a history |
| Prompts | Reusable instructions for repeated tasks | The user | «Prepare the monthly incident summary» |
Tools are the only block the model decides to invoke on its own, which is why they carry the most risk. Resources are served by the application, and prompts are launched by a person on purpose.
The practical reading is that the risk concentrates in the tools. A badly designed resource, at worst, shows data it should not. A badly designed tool can wipe a database because the model misread a sentence.
That is why it pays to start by exposing resources only, in read mode, and add tools afterwards, one at a time and with judgement.
4. MCP, RAG and function calling
There is a lot of confusion here and it is worth separating, because these are three different things that often live in the same project.
| What it does | When you want it | |
|---|---|---|
| RAG | Searches your documents and passes the relevant fragments to the model. Read-only, over fairly static content. | Answering about manuals, policies, contracts or internal rules. |
| Function calling | The model returns an object saying which function it wants to call. You define those functions in your application's code. | When you have two or three fixed actions and you are not going to change them. |
| MCP | Standardises the whole infrastructure around that call. The model discovers tools on connecting, authenticates and invokes them without you rewriting the application. | When you want live data, real actions and the ability to add capabilities without redeploying. |
5. How it connects, without the myths going around
Every message travels as JSON-RPC, and the specification defines exactly two transports. Worth clarifying, because there are outdated guides out there mentioning three or four.
stdio
On the same machine- The client launches the server as a child process
- JSON messages separated by newlines
- Fast, with no network in between
- For local tools and development environments
Streamable HTTP
Remote- Each message is an HTTP request to a single endpoint
- The reply arrives as JSON or as an event stream
- What you will use for a company server
- Allows long responses and real-time progress
The protocol holds no state
The current version is explicit about this. MCP has no protocol-level sessions. If your server needs to remember something between requests, such as a cart or an open case, it issues an identifier and receives it back as just another argument.
And here is a rule the specification puts in capitals. That identifier can never count as authentication. Holding it must not, on its own, let someone operate on another person's data. It sounds obvious and it is one of the failures the documentation itself describes as an attack vector.
6. What can go wrong
Giving a model the ability to act on your systems widens the attack surface, and it is worth looking at squarely. These are the risks the specification documents, not a list of generic fears.
| Risk | What happens | What prevents it |
|---|---|---|
| Hidden instructions | Text arriving from an email, a document or a tool's response contains orders, and the model obeys them as if they were yours. | Mark everything coming from outside as untrusted data, never as instructions. |
| Poisoned tools | A malicious server publishes tools with misleading descriptions so the model picks them or hands them credentials. | A register of approved servers and a review of what each one exposes before connecting it. |
| Confused deputy | The agent is tricked into using its legitimate permissions to do something the attacker could not do alone. | Per-client consent before forwarding to a third-party service. |
| Token passthrough | The server accepts a token that was not issued for it and forwards it to the destination system. | The specification forbids this outright. A server must not accept tokens that were not issued for it. |
| Compromised local server | A local server gets installed and runs code on your machine with your permissions. | Explicit confirmation showing the full command before running it, and process isolation. |
The part you cannot skip
All of the above rests on one simple idea. Irreversible actions need a person to say yes. A refund, a deletion, a transfer or a deployment should not run because a model judged it reasonable.
In practice that means two tool catalogues. A read-only one, always available, and a write one that only appears once the flow has reached a point where it makes sense and somebody has confirmed.
7. When it pays off and when it does not
This is the part usually missing from articles about MCP, because not everyone needs it.
It pays off if…
- Your team asks the same thing every day and the answer lives in a system that is a pain to get into. Order status, stock, due dates, a customer's history.
- You already use Claude or ChatGPT daily and notice half your time goes on copying data to paste into them.
- You have several systems that do not talk to each other and you want to query them together without building a data warehouse.
- You are going to repeat the pattern. If you will connect three or four systems, the standard pays for itself quickly.
It does not pay off if…
- You only need one specific action. A normal automation workflow is simpler, cheaper and easier to maintain for that.
- Your system has no API. With no way in there is nothing to expose, and the problem is a different one.
- Nobody in your company uses AI assistants. Building the infrastructure before the habit is building a motorway to an empty village.
- What you want is to be found. An MCP server does not make you show up in ChatGPT when someone asks about your industry. That is something else, and we cover it in how to show up in ChatGPT and Perplexity.
8. Where to start
| Phase | What happens | When to move on |
|---|---|---|
| 1. Read only | Expose queries over one or two systems, with no ability to change anything. Check that what it answers is true. | When the team trusts the answers without going to verify them. |
| 2. Access control | Real authentication, per-user permissions and a log of every call with who made it and what came back. | When you can reconstruct what happened at any point. |
| 3. Write with confirmation | Add actions that change data, each with human confirmation when it is irreversible. | Never entirely. This phase grows gradually. |
Phase 1 usually solves more than people expect. Querying well already removes a good share of the manual work, and it carries none of phase 3's risks.
The minimum you have to get right
- Every action runs with the permissions of the person who asked for it, not a service account that can do everything.
- The tool catalogue opens in stages, not all at once from the start.
- Everything arriving from outside is treated as data, never as instructions.
- Every call is logged with user, tool, parameters and result.
- Irreversible actions stop and wait for a person.
Sources
Questions about what MCP is and what it can actually do for your company
No, those are different things. An MCP server has to be installed on purpose, so only someone who already knows you and chooses to connect will use it. Being cited when someone asks about your industry depends on other work, which is optimising for generative engines.
Not necessarily. An automation runs a predefined process, always the same way. MCP makes sense when you want to ask different things each time and let the model decide what to query. They coexist well, and often the automation is still the right answer.
It depends entirely on how it is built. With per-user permissions, a scoped tool catalogue, full logging and human confirmation on anything irreversible, it is reasonable. Without those, it is not. The specification itself documents the specific attacks to prevent.
With any whose application supports the protocol, which today covers most of the ones used professionally. That portability is exactly the standard's argument, and it got stronger when governance moved to the Linux Foundation.
Then there is nothing to expose and the problem comes earlier. Before thinking about MCP you have to solve how anything gets into that system, and sometimes the conclusion is that it needs replacing.
It depends on how many systems have to be connected and whether you stop at querying or go as far as taking actions. A read-only server over a system with a decent API is a short project. An architecture with per-user permissions, auditing and controlled writes is another matter.
Let's talk about your
next project.
No sales pitch. A direct conversation about how automation and web development can transform your operation in the age of AI.
Support across Spain, LATAM and the USA
Spain · Colombia · Latam · USA
A direct reply and assessment in under 24 hours.