What is an MCP server? A business guide to connecting AI agents to your tools
What an MCP server is, what it changes for a company that wants AI agents working inside its real tools, and what to check before you install one or have one built: permissions, authentication, human approval, logging.

An MCP server is a small program that exposes one of your company's tools (a CRM, a database, a shared drive, a ticketing system) to an AI agent in a standard format. The agent can then read data or trigger actions in that tool without a custom, one-off integration.
MCP stands for Model Context Protocol. Anthropic open-sourced it on November 25, 2024 with a simple goal: replace bespoke integrations, one per data source, with a single protocol. On December 9, 2025, the protocol was handed to the Agentic AI Foundation (AAIF) under the Linux Foundation. According to the Linux Foundation, it was already supported by Claude, ChatGPT, Cursor, Gemini, Microsoft Copilot and VS Code, with more than 10,000 published MCP servers.
So if you deploy AI agents in 2026, you'll run into MCP. The question isn't whether to use it anymore. It's how to connect your tools without handing over the keys to the building.
How it works, in one minute
The official documentation describes three roles:
| Role | What it is | Example |
|---|---|---|
| Host | The AI application your teams use | Claude, ChatGPT, Cursor, Claude Code |
| Client | The part of the host that talks to one server | One client per connected server |
| Server | The program that exposes a tool or data | One server for your CRM, another for your product database |
A server can offer three things:
- tools: actions the agent can call (look up a customer, create a ticket, run a query);
- resources: data to read (a file's contents, a database schema);
- prompts: reusable instruction templates.
There are two ways to run one. A local server runs on the user's machine and serves a single client. A remote server runs over HTTP and serves a whole team. For remote servers, the documentation recommends OAuth for authentication.
What MCP changes for a business
Before MCP, connecting an AI assistant to an internal tool meant writing an integration specific to that assistant. Switching assistants meant starting over.
With MCP, you write (or install) one server per tool, and every compatible assistant can use it. Three concrete effects:
- Less vendor lock-in. Your CRM server works with Claude today and with another assistant tomorrow.
- One place for access rules. What the agent may read or do is decided in the server, not in each AI tool.
- A catalog that already exists. Many vendors publish their own MCP server. For internal tools, you need to build one.
MCP doesn't solve everything, though. The protocol standardizes access to tools. It says nothing about what the agent should know about your company, or what it's allowed to decide. We cover that in agents don't lack tools, they lack company memory and in what a good MCP server encodes about how your company works.
Install an existing server or build your own
| Situation | Sensible choice |
|---|---|
| The tool's vendor publishes an official server | Start there, after reviewing the permissions it asks for |
| Only a community server exists | Read it before installing it, or rewrite it: it is code that will touch your data |
| Internal tool, business database, in-house process | Build a dedicated server limited to the actions that matter |
| One user, occasional need | A local server is often enough |
| A whole team, sensitive data | A remote server with authentication and logging |
A dedicated server doesn't need to expose the tool's entire API. The best ones expose a few well-named actions that map to real tasks: "prepare the customer file", not "run any SQL query".
Six things to check before you connect an agent
This is where security is decided. The MCP specification sets the authorization and security rules. Here's what matters on the business side.
1. Level of authority. For each exposed tool, decide whether the agent can read, propose, prepare or execute. Start read-only. This is the grid from our article on the real risk of AI agents: authority (in French).
2. Authentication. A remote server must know who is calling it. OAuth is the recommended route. Avoid shared API keys pasted into every laptop's configuration.
3. No token passthrough. The specification forbids "token passthrough": an MCP server must not accept a token that wasn't issued for it and forward it as-is to another API. If a vendor offers you that shortcut, say no.
4. The user's permissions, nothing more. An agent acting for Julie should only see what Julie can see. A service account with access to everything, shared by the whole team, cancels out your existing permission model.
5. Human approval on sensitive actions. Emailing a customer, changing an amount, deleting a record: these go through a confirmation step. The protocol even includes a mechanism for a server to ask the user for input or confirmation.
6. Logging. Every tool call should leave a trace: who, what, when, and with what result. Without logs, you can't explain a mistake or answer a GDPR audit.
Where to start
A simple three-step method:
- Pick one use case, with one tool and one repetitive task. For example: pulling up a customer's history before a call.
- Connect a read-only server for a small team, and watch what the agent actually asks for. The logs quickly show which actions are useful and which are noise.
- Open up write access one action at a time, with human approval at first, and remove that approval only where the logs show the agent gets it right.
If you're scoping your first agent, our practical guide to AI agents for business and our POC-to-production checklist go further on measurement and going live.
In short
- An MCP server exposes a company tool to AI agents in a standard format.
- The protocol is open, governed by a neutral foundation since December 2025, and supported by the major assistants.
- It reduces vendor lock-in and centralizes access rules.
- Security doesn't come from the protocol alone: authority levels, authentication, user permissions, human approval and logging still have to be designed.
Want to connect your agents to your internal tools, or have an MCP server reviewed before you install it? Book a call with us.


