Your team uses an AI assistant every day. It writes decent emails and summarises long PDFs. But ask it which customers haven’t ordered since June, or what was agreed in last week’s project meeting, and it has nothing to go on. The answers live in your CRM, your shared drive and your order database, and the assistant can’t see any of them.
You can connect them. The real question is how many times you want to build the same connection. That is the problem the Model Context Protocol, or MCP, was made to solve. This post explains what MCP is, how it works, what it changes for an ordinary company and where you need to be careful.
MCP in one paragraph
MCP is an open standard for connecting AI applications to the tools and data they need. Anthropic introduced it on 25 November 2024 as an open specification with open-source code, not as a feature of its own product. By the end of 2025 it had been adopted by ChatGPT, Gemini, Microsoft Copilot, Visual Studio Code, Cursor and many other AI tools, and Anthropic counted more than 10,000 active public MCP servers. In December 2025 Anthropic donated MCP to the Agentic AI Foundation, a fund under the Linux Foundation that it co-founded with Block and OpenAI, so no single company controls it. The project’s own documentation compares it to a USB-C port: one agreed plug instead of a different cable for every device.
The problem: every app needs its own cable
Say you use three AI apps: a chat assistant for the office, a coding tool for your developers and a support assistant you built yourself. You want each of them to reach four systems: the CRM, the shared drive, the order database and Slack.
Without a standard, each pairing is its own integration. Three apps times four systems is twelve connectors, each written for a different app’s plugin format, each with its own login handling, each breaking on its own schedule. Add a fifth system and you build three more. Switch AI provider and you start again.
Without a standard
- Office assistant
- Coding tool
- Your support bot
- CRM
- Shared drive
- Order database
- Slack
Office assistant, Coding tool, Your support bot → CRM, Shared drive, Order database, Slack
With a shared protocol, each system is wrapped once, by an MCP server, and each AI app learns to speak MCP once. Now it is three plus four: seven pieces instead of twelve, and the gap grows with every app and system you add. More importantly, the connector to your CRM is no longer tied to one AI vendor.
With MCP
- Office assistant
- Coding tool
- Your support bot
- CRM
- Shared drive
- Order database
- Slack
Office assistant, Coding tool, Your support bot → MCP → CRM, Shared drive, Order database, Slack
How MCP works
The specification names three roles. They are easiest to understand from the top down.
Where MCP sits
- Host: your AI app A chat assistant, a coding tool or your own app
- MCP client Built into the host, one per connected server
- MCP server Wraps one system and describes what it can do
- Your system CRM, database, file store, ticketing
- Host: the AI application a person actually uses, such as a desktop chat assistant, a code editor or your own customer portal with an AI feature. The host decides what the model may see and do, and asks the user for consent.
- Client: the connector inside the host. Each client talks to one server.
- Server: a small program in front of one system. It describes what that system can do in a form any MCP client understands, and it makes the actual API calls or database queries.
The model never talks to your CRM directly. It sees a list of available tools with short descriptions, decides it wants to use one, and the host runs that call through the client. If you know how function calling works, MCP is the standard packaging around it. Our post on how AI agents use tools covers those mechanics.
What a server offers: tools, resources and prompts
An MCP server can offer three kinds of things:
- Tools: functions the model can call, such as
find_customer,create_ticketorget_invoice_status. This is where most of the value sits, and most of the risk. - Resources: data the app or the model can read, such as a customer record, a product sheet or the structure of a database.
- Prompts: ready-made templates a user can pick, such as “Prepare a brief for my call with this customer”.
A sensible CRM server for a sales team might offer five tools (search customers, read one customer, list open deals, add a note, create a task), the price list as a resource and two or three prompts the sales lead has written.
Local and remote servers
MCP defines two standard ways to connect.
- Local servers run on the user’s own computer. The AI app starts them as a small background program and talks to them through its standard input and output (the specification calls this
stdio). Developers use local servers to give an assistant access to files, a local database or command-line tools. - Remote servers run on a server and are reached over the web, through a transport called Streamable HTTP. This is the shape that matters for most companies: one server for your CRM, hosted once, used by everyone who has permission. Many software vendors now publish remote MCP servers for their own products.
The current version of the specification, released on 28 July 2026, removed long-lived sessions from the protocol. Each request now stands on its own, so a remote MCP server can run behind an ordinary load balancer like any other web service.
Who may do what: authorization
Authorization is optional in the specification, which tells you something: MCP describes how an app asks for access, not who should get it. That part is your decision. For remote servers, the specification defines a sign-in flow based on OAuth 2.1, the same family of standards behind “Sign in with Google” or Microsoft. In practice:
- A user connects their AI app to your MCP server.
- The app sends them to your normal login, for example Microsoft Entra ID or Google Workspace.
- They sign in and approve what the app may do, for example read customers but not delete them.
- The app receives a token that works only for that one server, with only those permissions.
Local servers skip this and read their credentials, such as an API key, from the local configuration. That is convenient, and it is also why local servers need care: whatever key you put there, the AI app can use.
The design rule that matters most is simple: the server should act with the permissions of the person using it, not with an admin key that sees everything.
What it looks like in practice
Here is a sales manager using an assistant connected to the company CRM through an MCP server.
- You: Which customers in Slovakia haven’t ordered since June?
- Tool call: crm.search_customers(country: SK, last_order_before: 2026-06-01)
- Result: 14 customers · 3 with open deals
- Tool call: crm.list_deals(status: open, customers: those 3)
- Result: Wholesaler in Žilina: quote sent 12 Aug · Hotel group: demo booked · Print shop: no activity since July
- AI: Fourteen customers. Three have open deals: the Žilina wholesaler has a quote waiting, the hotel group has a demo booked, and the print shop has gone quiet since July. Shall I draft an email to the print shop?
- You: Yes, and add a follow-up task for Peter.
- Creating a task changes data: the app asks the user to confirm
The same server works with the office assistant today and with a different AI provider next year, without rebuilding the connection.
We built something similar for Shovels: Charlie, an assistant that answers questions about building permits and contractors. It uses MCP server integrations, so the model queries the live database instead of guessing from what it learned in training.
What MCP means for your company
If you buy AI tools
Before you choose an assistant, check which of your core systems already have an official MCP server, and whether the AI apps your team uses can connect to remote servers. Prefer servers published by the system’s own vendor over anonymous ones. Ask what permissions the server needs and whether it respects each user’s access rights.
If you run your own systems
If your company depends on an internal tool, a custom database or an ERP extension, an MCP server is a clean way to make it available to AI. You build it once, you decide exactly which operations it exposes, and any MCP-capable app can use it. You also stay free to change AI provider, because the integration belongs to you, not to one vendor’s plugin store. This is often a small project: a server with a handful of well-designed tools on top of an existing API. Our work on internal tools shows what usually sits behind such a server.
If you sell software
Your customers will increasingly want their AI assistants to work with your product. A well-scoped MCP server, with proper sign-in and a short list of safe tools, is becoming part of what a modern API looks like.
Security: what MCP does not do for you
MCP standardises the connection. It does not make the connection safe. The specification itself warns that tools represent arbitrary code execution and that the host must get the user’s explicit consent before it invokes a tool. Four risks to keep in mind:
- Untrusted servers. A local MCP server is a program running on your computer with your permissions. Installing one from an unknown repository is like installing any unknown software.
- Tool descriptions are text the model reads. A malicious server can hide instructions in them. The specification says to treat tool descriptions as untrusted unless they come from a server you trust.
- Too many permissions. A server running on an admin API key turns every user into an admin, through the AI.
- Prompt injection. When an assistant reads emails, web pages or documents through one server and can send data out through another, a hidden instruction in that content can make it leak data. Mixing servers from different sources makes this easy to miss.
We cover the defences, from least privilege to approvals and logs, in keeping AI agents safe.
When you don’t need MCP
MCP pays off when several AI apps need the same systems, or when you want people to plug their own assistant into your data. You often don’t need it:
- One AI feature, one system. If your invoice process calls a model to read a PDF and then writes to your ERP, a direct API call is simpler. There is nothing to standardise.
- Fixed workflows. An automation in n8n or Make that runs the same steps every time doesn’t need a protocol for discovering AI tools. Our post on workflows, AI workflows and agents helps you tell these apart.
- A simple rule does the job. If the task doesn’t need AI, it doesn’t need a protocol for AI either.
Before you connect an MCP server
Before you connect an MCP server
- Know who published it The system’s vendor or your own team, not an unknown repository
- Read every tool Names and descriptions; switch off the ones you don’t need
- Read before write Start with read-only tools, add write tools one at a time
- The user’s permissions, not admin Each person sees only what they can already see
- Approval for risky actions Sending, deleting and paying need a person to confirm
- Log every call Who asked, which tool, which inputs, what came back
- Test with real questions And with a few attempts to trick it
- An owner Someone who updates the server when the system changes
What to do next
- List the three or four systems your team most often wishes the AI could see.
- Check which already have an official MCP server, and which of your AI apps can connect to it.
- For the rest, start with one read-only server on top of the system’s existing API, used by one team.
- Add write actions only after a few weeks of reading the logs.
If you want an MCP server for an internal system, or an assistant that uses one, we can work out the first step together in a 30-minute call.
