MCP (Model Context Protocol) is an open standard for connecting AI assistants to the systems where your data and tools live. It replaces one-off custom integrations with a single interface, so any compliant AI client can use any compliant server. Anthropic open-sourced it, and OpenAI, Google, Microsoft, IBM and Amazon have since adopted it.
The shorthand that has stuck is "USB-C for AI tools", and it is a fair one. Before USB-C, every device needed its own cable. Before MCP, every combination of AI assistant and business system needed its own integration.
The problem it solves
Say you have four AI assistants in use and six systems worth connecting: a CRM, a helpdesk, a data warehouse, a document store, an ERP and a calendar. Connecting each assistant to each system directly is twenty-four separate integrations, each with its own auth, error handling and maintenance burden. Change one system's API and you fix it in four places.
With MCP, each system exposes one server and each assistant speaks one protocol. Twenty-four integrations become ten things to maintain, and a new assistant costs nothing extra to connect. That is the entire commercial argument, and it is why adoption moved faster than anything comparable in recent memory.
The adoption numbers
Reported figures for 2026, worth attributing rather than stating as fact: roughly 28% of the Fortune 500 have implemented MCP in under eighteen months, around 78% of surveyed enterprise AI teams had MCP-backed agents in production as of July 2026, and SDK downloads reached roughly 97 million a month by March 2026, up from about 100,000 at launch (Digital Applied, CIO). These come from vendor and trade sources rather than audited surveys, but they agree with each other and with what we see in client environments.
What an MCP server actually exposes
Three things, and the distinction matters when you scope one:
- Tools. Actions the assistant can take: create a ticket, look up an order, post a journal entry. These are the ones that need approval design, because they change your data.
- Resources. Read-only context the assistant can pull in: a document, a record, a report.
- Prompts. Reusable templates that encode how your organisation wants a particular job done.
The four problems enterprises actually hit
Connecting an assistant to a system is the easy part. These are what the rollout runs into:
- Authentication and identity. The assistant must act as the user, not as a service account with universal access. If your MCP server can read every record regardless of who is asking, you have replaced a permission model with a hole. Wire it to your existing SSO and carry the user identity through.
- Audit trails. When an agent takes an action, you need to know which user, which tool, which arguments and what result. This is the requirement most first implementations skip and most security reviews stop on.
- Gateway behaviour. Once more than a handful of servers exist, something has to sit in front of them: routing, rate limits, allowlists, credential handling. Organisations that skip the gateway end up retrofitting it under time pressure.
- Config portability. Server configuration tends to live on individual machines. Moving it into managed, version-controlled configuration is dull work that becomes urgent the moment you go past a pilot team.
Off-the-shelf connector or custom server?
| Situation | Use | Why |
|---|---|---|
| Common SaaS, standard use | Existing connector | Someone has already built and maintained it |
| Internal or legacy system | Custom server | No connector exists and none is coming |
| Standard SaaS, non-standard permissions | Custom server | Generic connectors rarely model your access rules |
| Actions with financial consequence | Custom server | You need approval steps and audit built in |
A useful way to think about the spend: integration work built as MCP servers is reusable across every future AI project. The first project pays for the connector; the second and third get it free. That is the strongest argument for doing integration properly rather than embedding it inside one application.
Where to go next
If you want the technical version, with server design, transport choices and deployment patterns, our engineering deep-dive on MCP servers for business integration covers it. If you want servers built against your systems, that is our MCP development work, and you can start with a conversation.
Common questions
What is MCP in AI?
MCP is the Model Context Protocol, an open standard for connecting AI assistants to external data sources and tools. Instead of building a custom integration for every combination of assistant and system, each system exposes one MCP server and any compliant AI client can use it. Anthropic open-sourced it and the major AI providers have adopted it.
What is the difference between MCP and an API?
An API is how two specific pieces of software talk to each other. MCP is a standard way to describe an API so that any AI assistant can discover and use it without custom integration code. An MCP server usually sits in front of your existing APIs, adding tool descriptions, permission handling and audit logging that language models need.
Do we need a custom MCP server?
Use an existing connector for common SaaS with standard access patterns. Build a custom server when the system is internal or legacy, when your permission rules differ from what a generic connector models, or when the agent will take actions with financial consequences that need approval steps and audit trails.
Is MCP secure?
MCP is a protocol, so security depends on implementation. The three requirements that matter are carrying the end user identity through to the underlying system rather than using a shared service account, logging every tool call with user, arguments and result, and putting a gateway in front of your servers for routing, rate limiting and credential handling.