Every useful AI assistant eventually needs to reach outside the chat window: to look up an order, read a file, query a database or open a ticket. Until recently each of those connections was custom work, written separately for each model provider and each application.
The Model Context Protocol, or MCP, is an open standard for those connections. Anthropic introduced it in November 2024, and it has since been adopted across the industry, with support in tools and SDKs from OpenAI, Google and Microsoft among others. It is often described as a USB-C port for AI applications: one shape of connector, many devices.
How MCP works in plain terms
MCP has two sides. An MCP server wraps a system, such as your CRM, a document store or an internal API, and describes what it offers. An MCP client lives inside the AI application and connects to those servers. A server can expose three kinds of things:
- Tools: actions the model can call, such as search_orders or create_invoice, each with a defined input schema.
- Resources: data the application can read and give to the model as context, such as a file or a record.
- Prompts: reusable templates for common tasks, offered to users of the application.
Why it matters for businesses
- Build once, use in many places: an MCP server for your ERP can serve an internal assistant, a coding tool and an agent without being rewritten for each.
- Less lock-in: because the protocol is shared, switching or mixing model providers does not mean rebuilding every integration.
- Clearer boundaries: tools are declared explicitly, which makes it easier to review exactly what an assistant is able to do.
The security questions to ask before connecting anything
MCP standardises the connection; it does not make the connection safe. A model that can call tools can be manipulated by text it reads, through prompt injection, into calling them in ways you did not intend. Treat any MCP server as code with access to your systems:
- Only install servers you trust or have reviewed. A third-party server runs with whatever credentials you give it.
- Scope credentials per server, and prefer read-only access unless writing is the point.
- Require confirmation for actions that change data, send messages or spend money.
- Log tool calls centrally so you can see what the assistant actually did, not just what it said.
Where to start
Pick one internal system your team asks about constantly, often a knowledge base or a reporting database, and expose it read-only through an MCP server. You get a useful assistant quickly, and you learn how your people actually use it before you give it anything that can write.
