What is an MCP server and why it shifts AI integrations

An MCP server is a standardized bridge between an AI model and a company tool. It publishes what that tool can do in a format any compatible agent understands, without writing a custom integration for every model.

The Model Context Protocol stopped being a novelty a while ago. It is now the usual way to connect agents to data and tools, and it shows up in the technical proposals received by companies considering an agent. This article explains what an MCP server is, what problem it actually solves, and what the decision implies for a company that wants to integrate an agent with its ERP, its CRM, email and internal files. No promises, no futurology.

What an MCP server is

An MCP server publishes the actions a tool can execute (read an email, create a contact in the CRM, search for a file) and the data it can read, in a standardized format that any agent compatible with the protocol understands. It is not a product you buy: it is a small piece of software that sits in front of a tool you already have.

Three clarifications that prevent most of the misunderstandings:

• MCP is an open protocol, not a platform. Anthropic published it at the end of 2024 and maintains it as an open specification. You do not buy MCP, you implement it.
• The server is per tool, not per model. One server for your ERP works for Claude, for GPT and for Gemini at the same time.
• The tool’s API still exists underneath. MCP is the layer that makes it consumable by an agent generically, not a replacement for the API.

In 2026 this is no longer a bet: the SDKs of the major model providers speak the protocol, there are servers maintained by the tool vendors themselves, and there are public directories of community servers. The core idea is the same as in the first specification: instead of writing a custom connector for each model and tool combination, the server exposes a common interface and the models speak that same language.

The problem it solves

Until now, every time you wanted an agent to read your Holded, write to your HubSpot, or query an internal sheet, the same thing happened: a custom connector. If you switched models (from GPT to Claude, for instance), a good part of that connector had to be rewritten. If an internal tool got updated, the connector stopped working and no one knew until the agent failed.

The result, in practice, is that many AI projects in SMBs stayed at the pilot stage. The cost of maintaining twenty custom connectors against five different models was prohibitive, and no one wanted to be locked into a single AI provider out of fear of technical dependency.

MCP changes that equation. You build one MCP server for your Holded, once. It works with Claude. It works with GPT. It works with Gemini. It works with whatever model comes out next year. Your integration does not expire every six months at the pace of the marketing of the big AI platforms.

How it works, without going into architecture

Three pieces:

1. MCP server. A small process (usually a Node, Python, or Go service) that knows how to talk to your specific tool: your CRM, your database, your ticketing system. It exposes “tools” (actions the agent can execute) and “resources” (data the agent can read).
2. MCP client. The environment where the agent lives: Claude Desktop, Cursor, an internal application built on top of the Anthropic or OpenAI SDK. The client knows how to discover the available MCP servers and how to invoke their tools.
3. Model. The AI model itself (Claude, GPT, Gemini, open-weights). The client passes the list of available tools, the model decides which to invoke based on the conversation or the workflow, and the server executes the action against the real tool.

The key point is that the three components are interchangeable. You swap the model, the MCP servers keep working. You swap the client, the servers keep working. You swap the server of a vendor (for example, you migrate from Holded to Sage), you rewrite only that server, everything else stays the same.

A concrete example

Imagine an SMB with Holded as ERP, HubSpot as CRM, and an internal Drive with proposal templates. You want an agent that, when a client sends an email asking for a quote, looks up the client data in HubSpot, retrieves the latest conversation, checks the available products in Holded, and prepares a draft proposal using the Drive template.

Without MCP, this requires four custom integrations (email, HubSpot, Holded, Drive), each tied to the specific model the agent uses. If you change models in six months, you rewrite all four.

With MCP, you set up:

• An MCP server for Holded (or use a community one if it exists).
• An MCP server for HubSpot.
• An MCP server for Drive.
• An MCP server for your email system.

And you connect the agent to the MCP client of your choice. Any compatible model can run the complete workflow. The day the model of the moment improves enough, you swap it and the servers keep working.

Why it could replace today’s integration systems

MCP is displacing three integration families that were the norm until recently:

• Proprietary plugins. The early versions of plugins for ChatGPT and similar tied each integration to a specific platform. MCP removes that coupling: the same integration serves any compatible client.
• Connectors in automation tools. Platforms like Zapier or Make offer thousands of connectors, but each one needs to be maintained by the platform itself. With MCP, a server can be maintained by the vendor of the original tool, by the community, or by the client.
• Specific SDK wrappers. Today, integrating OpenAI Function Calling with your internal tools means writing wrappers tied to its SDK. MCP standardizes the interface: the wrapper stops being part of the agent and becomes part of the tool.

The displacement is not total, and will not be in the short term. Established platforms have commercial incentives to keep their own connectors, and many teams stay on custom integrations simply because they are already written and working. But the historical pattern repeats itself: when an open protocol that solves a real problem appears (HTTP, SMTP, OAuth in their day), proprietary options end up converging. MCP already occupies that place for connected AI.

What MCP does not solve

It is worth putting optimism in its place. MCP is not:

• A recipe for building reliable agents. The protocol standardizes how the model talks to the tools. The reliability of the agent depends on the prompt, the model, the data quality, and above all the bounded workflow the agent is asked to execute. A perfect MCP server does not save a poorly defined agent.
• A guarantee of security. The server exposes tools to the model. If those tools include “delete CRM records” without human confirmation, the agent can execute them. The permission layer, kill-switch, and human validation remain the implementer’s responsibility.
• A replacement for business logic. The MCP server is a bridge. The rules about which clients are priority, which products are active, which cases require escalation still live in the server’s code or in the original tool.
• A shortcut to skip the discovery phase. Even though the technical integration is faster, the prior work of defining the workflow, the success metric, the kill-switch, and the human fallback remains the same.

What to check before connecting an agent to an MCP server

Guides about MCP are written for whoever picks a server. The question a company asks is a different one: what does granting access imply. Four checks before connecting anything to real data.

1. Which tools read and which ones write. A server that only reads invoices and one that can issue them are the same kind of component with very different consequences. Ask for the tool list split into two columns before approving the connection. If the vendor has not written it down, the conversation is not mature yet.

2. Who maintains the server. A server published by the tool vendor, a community one and a custom-built one have very different maintenance cycles. The community one can go unmaintained the day the API changes, and the agent fails without warning.

3. Where the human confirmation lives. The protocol does not decide which actions need someone to say yes. That rule is set by whoever implements it. Before production, it has to be written down which operations an agent may execute alone and which ones stop and wait for a person.

4. What happens the day you switch it off. If you disconnect the server, the process has to keep running by hand. The kill-switch and the human fallback are not optional just because the integration is standard.

In serpixel’s own internal operation the agents connect to Holded and Notion through MCP servers, and those four questions are the same ones we apply before granting access to a client’s tool. It is an order of work, not a guarantee: what decides the outcome is still the bounded process behind it.

What changes for an SMB

Three concrete things.

1. Integration cost going down. Connectors already written (published by the community or by the tool vendor itself) reduce custom work. This lowers the threshold at which an agent makes economic sense, especially for medium-volume processes.

2. Less dependency on the AI provider. An SMB that invests in an MCP architecture is not locked into Claude, GPT, or Gemini specifically. It can change models based on reliability or cost without rewriting the integration. The mechanical layer of the workflow (MCP server) survives the model changes.

3. Ability to combine tools from different sources. A single agent can query an MCP server for Holded, another for a custom internal system, and another for a public API, with no additional integration cost. This opens up workflows that were previously prohibitive due to the complexity of combining several tools.

What does not change is the human part: defining the workflow, validating what the agent does, reviewing the success metric, keeping the kill-switch operational. MCP frees the mechanical layer of integrations; it does not replace the team that decides what to automate and how. The layer where the team adds value (judgment, ambiguous decisions, client relationships) stays untouched.

How we apply this at serpixel

serpixel (Clever European Business, S.L.) is a custom implementation agency for companies with real daily operations: orders, bookings, invoices, timesheets. It works across four service lines: AI agents, process automation and integration, custom software, and websites. The agents integrate with the tools the client already uses (ERP, CRM, email, WhatsApp Business). The proposal is model-agnostic (Claude, GPT, Gemini), the code and data stay with the client, and every implementation includes a kill-switch, a human fallback, and an evaluation harness.

In practice, this means the agents we build follow the same separation MCP standardizes: the integration layer (each tool, in its own module) on one side and the orchestration layer (what the agent does with those tools) on the other. When a client tool already has an MCP server maintained by the vendor or the community, the agent connects to it instead of dragging along a custom connector. When it does not, the connector is built once and reused on the next project that uses the same tool.

The advantage for the client, in any case, is the same: the investment in the agent does not expire every time a new model comes out. The mechanical layer of the process survives, the human team keeps doing what only people do well, and the maintenance cost stays predictable. serpixel accompanies that technical decision from the start of the project, before writing a single line of code.

What to do now

If you have a bounded workflow in mind and you wonder whether MCP changes the conversation, the short answer is that it already has: connecting an agent to your tools costs less than it did two years ago and ties you to a vendor far less. But the useful conversation is not which protocol you will use, it is which specific workflow you have and which tools it touches.

A 30-minute discovery session is enough to answer three questions: whether the workflow fits an agent, which tools would have to be integrated, and which success metric makes sense to measure before budgeting anything. If you want to have that conversation, let’s book 30 minutes on Calendly. No commercial pressure, no commitment to sign, just the space needed to understand whether the project makes sense and, if it does, where to start.