An MCP server is a small piece of software that exposes one of your systems — a database, a CRM, an internal API, a folder of documents — to an AI assistant in a format the assistant can actually use. It is a translation layer, not a product, and it is the thing that turns "our AI can write emails" into "our AI can look up the customer's last three invoices and then write the email."
The protocol behind it, the Model Context Protocol, was published by Anthropic in November 2024 and donated to the Linux Foundation's Agentic AI Foundation in December 2025, with AWS, Google, Microsoft, OpenAI, Bloomberg and Cloudflare backing the move. That donation matters more than it sounds: it means the integration standard you build against is no longer one vendor's product decision.
We have built four of these — for search analytics, for content publishing, for a knowledge base, and for a whiteboard tool — and we run them daily. This is what we would want a technical director to know before commissioning one.
What problem does an MCP server actually solve?
Before MCP, every AI-tool integration was bespoke. If you wanted an assistant to read from your ERP, someone wrote glue code for that assistant and that ERP. Change the assistant and you wrote it again. The industry ended up with an M×N problem: every model times every system.
MCP collapses that to M+N. You write one server for your ERP, and any MCP-capable client can use it — Claude, ChatGPT, Gemini, Copilot, a custom agent your team wrote, a CLI tool. The number of integrations you maintain becomes the number of systems you own, not the number of systems times the number of AI tools you might try.
That is the entire pitch, and it is a genuinely good one. It is also why adoption moved so fast: reported SDK downloads went from roughly 2 million at launch to about 97 million a month within sixteen months, with 9,400+ public servers now listed.
What is inside an MCP server?
Three things, and it is worth knowing the difference because they behave differently in practice.
Tools are actions the model can invoke — create_invoice, search_orders, send_reminder. The model decides when to call them and with what arguments. These are the powerful ones and the dangerous ones.
Resources are read-only content the client can pull in — a document, a config file, a record. Passive. The client fetches them; the model does not decide to.
Prompts are reusable templates the server offers the user, surfaced as slash-commands or shortcuts. Underused, and the cheapest way to make a server usable by non-technical staff.
Most teams build a server that is 90% tools and skip the other two. That is usually a mistake — prompts in particular are how you encode "the right way to ask" so that every employee is not reinventing it.
Is this just an API with extra steps?
No, and the difference is the point.
An API is written for a programmer who has read the documentation, knows which endpoint to call, and handles the errors in code. An MCP server is written for a model that has read nothing except your tool descriptions and will decide, on the fly, what to call and in what order.
This changes the design brief in ways that surprise people:
| Conventional API | MCP server | |---|---| | Names can be terse; docs live elsewhere | The tool name and description are the documentation | | Return everything; the client filters | Return the minimum; every token costs money and attention | | Errors are status codes | Errors must be sentences that tell the model what to do next | | Granular endpoints are good design | Too many tools degrade the model's ability to pick correctly | | Idempotency is a nice-to-have | Idempotency is a safety control |
The last two are where most first attempts go wrong. We shipped a server with forty-one tools and watched the model reliably pick the wrong one; consolidating to nineteen better-named tools fixed more "AI quality" complaints than any prompt change.
What does it cost to build one?
For a single, well-scoped internal system with an existing API: a few days to a working server, one to two weeks to something you would let a non-engineer use unsupervised. The SDKs (TypeScript, Python, and others) handle the protocol; you are writing the tool definitions and the auth.
The cost is not the build. It is these three, in order of how often they are underestimated:
- Authentication and identity. The hard question is not "can the server reach the CRM" but "as whom." A server that acts with one shared service account has just given every user the permissions of the most privileged one. Doing this properly means per-user OAuth, and it is most of the engineering.
- Deciding what not to expose. Every write action you add is a thing an agent can do wrong at 3am. Read-only servers are dramatically cheaper to govern and cover more use cases than people expect.
- Maintenance as the spec moves. The stable specification is dated 25 November 2025 with the next revision expected mid-2026, changing transport and session handling. This is a young standard under active governance. Budget for revisions.
Where does it go wrong?
Prompt injection through data. If your server returns content from an untrusted source — a support ticket, an inbound email, a scraped page — that content can contain instructions, and the model may follow them. A server exposing both "read inbound email" and "send payment" is a genuine security problem, not a theoretical one. Separate read-from-untrusted and write-with-consequences into different servers with different permissions.
Over-broad tools. run_sql_query is easy to build and impossible to govern. get_orders_for_customer(customer_id, since_date) is more work and is the version you can actually approve.
No audit trail. When an agent does something wrong, "which tool call, with which arguments, on whose behalf" is the first question and most servers cannot answer it. Log every call with the user identity before you go live, not after the incident.
Treating it as an AI project. It is an integration project. The people who should own it are the ones who own the underlying system, not the innovation team.
Should your company build one?
A reasonable test, in order:
- Do people in your business repeatedly ask questions that require someone to look something up in a system and retype it? If no, stop here.
- Does that system have an API, or at least a database you can read? If no, the MCP server is not your first problem.
- Can you name the ten questions it should answer? If you cannot, the scope will sprawl and the tool count will explode.
- Are you willing to run it read-only for the first month? If not, be honest that you are taking on a governance project, not a productivity one.
Reported figures put MCP server implementation at roughly 28% of Fortune 500 companies as of early 2026, against about 80% deploying AI agents in some production workflow. The gap between those two numbers is the interesting part: most organisations have agents that cannot reach their own data. That is the problem this solves, and it is the reason the term is one of the few in this field whose search volume is still climbing rather than settling.
Frequently asked questions
Is MCP owned by Anthropic? Not any more. It was created by Anthropic and donated to the Linux Foundation's Agentic AI Foundation in December 2025. Governance is now a community process with multiple major backers.
Do I need a separate server for each AI tool? No. That is the point of the standard — one server serves any MCP-compatible client.
Can an MCP server run entirely inside our network? Yes. Servers can run locally or self-hosted; nothing requires exposing them to the public internet. For sensitive systems this is the default we recommend.
What is the difference between an MCP server and an AI agent? The agent decides what to do. The MCP server is what it can reach. An agent without servers can only talk; a server without an agent does nothing.
Is it worth building if we might change AI vendors? That is one of the stronger reasons to build it. The server outlives the model choice.
Sources: Model Context Protocol specification · MCP adoption statistics, 2026 · Enterprise MCP adoption analysis. Adoption figures are third-party estimates and should be read as directional.