An analyst wants their assistant to answer questions about sales figures. They find an MCP server for the data warehouse, paste a connection string into a config file, and within ten minutes the assistant can query the database.
That is exactly what MCP was designed for, and it works: the assistant now answers questions that used to mean asking a colleague for a report. It also means that, without a ticket or a procurement decision, there is now a connection between an AI service and the system holding revenue data. Both sides are worth understanding.
What is MCP, and what problem does it solve?
The Model Context Protocol is an open standard, introduced by Anthropic in November 2024, describing how an AI assistant talks to systems outside itself. The specification is public.
The problem it solves is real. Before MCP, every assistant-and-system pair needed its own integration: one for this assistant with that CRM, another for a different assistant with the same CRM. With a shared standard you build the integration once and any conforming assistant can use it.
That is the move USB made for peripherals, and the consequence is the same: the number of connections climbs because the barrier is gone.
What does an MCP server do?
An MCP server is a small program that speaks in two directions.
On the system side it connects to whatever you want to expose: a mailbox, a calendar, a database, an API or simply files on a disk.
On the assistant side it advertises the available tools. Not as documentation for humans, but as a machine-readable description: this tool is called find_customer, it expects a name, it returns a customer record. The assistant reads that list and can then invoke the tools.
An important detail: the assistant decides when to call which tool. You ask for sales figures, and the model determines which calls that requires. That is exactly what makes an agent an agent.
What can you do with it?
With a few connections, an assistant becomes a colleague who can look inside your own systems. It prepares a meeting from the calendar and the latest emails on the subject. It pulls up a customer record before you call back. It answers a question about sales figures without anyone running an export. Or it drafts a ticket in the system your team already uses.
More and more vendors now offer their own MCP server for their product. That makes it easier to start with a connection built by whoever built the system, rather than by a stranger.
What should you watch for?
Not the protocol: that is a specification, and a good one. The risk lies in what grows up around it.
It is somebody else's code. An MCP server is a program you install that gains access on your behalf. That is a supply chain, with the same questions as any dependency. In July 2025 researchers disclosed CVE-2025-6514, a command injection flaw in mcp-remote, a widely used proxy with hundreds of thousands of downloads. Not unusual for young software, and a good reason to know what you are running. OWASP maintains an MCP security cheat sheet covering this ground.
Permissions exceed the task. Connections often request full access where read-only would do. That is easier for the developer, and wider than necessary.
Tokens do not expire. A granted token typically stays valid until somebody revokes it, including after the user changes their password. Short-lived scoped tokens are the recommendation; long-lived ones are the practice, because they cause less friction.
Nobody assessed it. The biggest of the four. The connection was made by someone trying to work faster, which is how shadow AI always arrives.
How is this different from pasting text into a chatbot?
The first wave of shadow AI was a browser tab: somebody opened a chatbot and pasted something in. Unwelcome, and bounded by what that person pasted.
An MCP connection is a door. What is shared is not text but access, and that access persists after the employee goes home. What travels through it afterwards depends on what the assistant decides it needs.
On top of that, an assistant with integrations also reads external content, which makes it susceptible to instructions hidden in that content. See what prompt injection is.
How do you set up a connection well?
- Know which connections exist. On managed machines you can see which MCP servers are installed. Without device management, you are left asking around, and the answers will be incomplete.
- Assess provenance. From the system vendor itself, or from an unfamiliar repository? The same distinction you apply to any dependency.
- Narrow permissions at connection time. Read where reading suffices. This is the moment to do it, because nobody revisits it afterwards.
- Let tokens expire. And make sure there is somewhere they can be revoked.
- Treat it as a vendor. The same questions as in approving an AI tool, because that is what it is.
Start with one connection that genuinely saves time, preferably using the system vendor's own MCP server, with read permissions and a token that expires. Write down who set it up and what for. That way you get the benefit of MCP, and a year from now you still know which doors are open and how to close them.
