An MCP server is a standard way to give an AI application access to outside systems. It exposes tools, data and context that the application can discover and use through the Model Context Protocol. That is the textbook answer, and it is the easy half.
Here is the half the textbook leaves out.
A project manager asks the agent which of last quarter's projects lost money. The agent is connected to the ERP through exactly such a server. It comes back with a short, confident list of projects, and the list is wrong.
Nothing was broken. The connection worked, the query ran, the data came back. What the agent did not know is that this company books retail projects without a fiscal year, so the "last quarter" filter quietly dropped a whole class of them; that the margin field it sorted on is calculation-internal and not what the customer actually paid, so projects surfaced as losses that were never losses at all; and that a project code starting with R means something different from one starting with G. The values are in the database. The rules for interpreting them are not. They live in the heads of the four people who have worked here longest.
The connection did its job. What was missing was the meaning, and that is the difference between an MCP server that works in a demo and one that holds up in production. Reaching the data is the part the protocol standardises. Carrying the meaning is the part that falls to you, and it is the half most MCP explainers barely mention.
I run twelve of them in production at a roughly 350-person HVAC company, 97 tools across the estate, used on a given day by around twenty project managers and back-office staff and by more than a hundred people over the past few months. Most of them have never written a line of code. Some of the numbers in this post are unflattering, and they are the reason it is worth writing another explainer at all: every other one paraphrases the spec, and the spec cannot tell you what happens when non-developers ask real questions of real business data.
The half the protocol handles, and the half it doesn't
For this post, I use agent for a model-driven system that can choose and invoke actions, rather than only generate a response. To do anything useful it needs two things: a way to reach a system, and a way to know what it is looking at.
Before MCP, reaching a system often meant bespoke integration work, one connector per tool per client, rebuilt each time the client changed. MCP standardised that boundary. A server exposes tools, any compatible client can call them, and the same server can be reused across compatible clients instead of rebuilding the integration around every model or application. The protocol handles that half well, which is why it spread as fast as it did. Not everything around it is settled, auth and discovery and deployment are still real engineering, but the protocol surface is standardised now.
The second half was getting far less attention when I started, and it is the one the opening turns on. Reaching the ERP was never the problem. Knowing that R and G mean different things was.
What an MCP server actually is
An MCP server can expose several things to a client: tools it can call, resources it can read, and prompts it can reuse. For the production work in this post the surface that matters most is tools. Each tool carries a name, a schema for its arguments, and a description. The model is presented with those signals and uses them to decide whether a tool fits the question, then calls it.
AI application → MCP client → MCP server → business system
MCP standardises the boundary between the AI application and the server. It does not supply the business semantics behind the server, and that is the part the rest of this post is about.
The description is the part that gets treated as an afterthought and is actually one of the most important parts of the interface.
The description is not documentation for a human who got stuck. It is part of the interface the model reasons over.
Take a single field, energielabel, that comes back as null. That null can mean four different things: the building has no label, one was never registered, a label does not apply to this building type, or the data has simply not loaded yet. Expose the field with a one-line description and the agent reports "no energy label", confidently, when the truth might be any of the other three. Write those four cases into the description, with how to tell them apart, and the agent stops guessing and says which one it is actually looking at. Same data, same tool, same model. The only thing that changed was how much meaning travelled with the field, and it was the difference between a right answer and a fluent wrong one.
Why most of them do not work
Many MCP servers begin as wrappers, and there is nothing wrong with that as a starting point. A wrapper is a perfectly good scaffold; the mistake is treating the scaffold as the finished interface. Someone points a generator at an existing API, every endpoint becomes a tool, and in an afternoon the agent can reach the whole system. The trouble is that reach is all it gets. A wrapper hands the agent every endpoint and no understanding, so it can call everything and answer almost nothing correctly, which is exactly the failure in the opening. It is the emptiness I keep coming back to: access without meaning.
It is not rare. Across 856 tool descriptions on 103 public servers, 97% carried at least one critical smell: a name that says nothing, an enum with no meaning attached, a field whose null could mean four different things. And the failure is quiet. A thin description does not raise an error. It produces a well-written answer that happens to be false, which is worse, because no one goes looking for the bug behind a fluent reply. If you want the shape of the whole spectrum, from hollow wrapper to server that writes back, I laid it out as six levels.
What a good one looks like
The move is not clever. Bind the domain meaning to the capability, close to the data and operation it describes, rather than leaving it in a wiki nobody reads or in the head of the colleague who is on holiday. Tool descriptions and schemas are the first place to start, but the principle is broader: the meaning should travel with the capability.
The question is where that knowledge comes from without it becoming a second full-time job, and the workflow that ended up working for us was to let the model do the first pass. Point it at the real data, let it explore and flag the patterns it is unsure about, and hand a domain expert the shortlist. They confirm or kill the uncertain ones in an afternoon. In our own server-building, roughly 90% of the candidate semantics the model surfaced survived domain-expert review. The roughly 10% it got wrong is precisely the part that would otherwise have shipped as confident and wrong, so the expert's afternoon is spent exactly where it pays. Everything countable, you count yourself; the expert's time goes only on what the data cannot answer.
That is the cost, and it is worth stating plainly because people assume it is larger. For us the initial review has been closer to an afternoon per server than a design cycle.
What it looks like in production
The estate is twelve servers and 97 tools. On a given day around twenty people use these capabilities; over a hundred have used them in recent months. This is a 350-person HVAC company, not a tech giant, with a small IT team and no prior AI in the building.
I want to be honest about the shape behind that number, because a single figure flatters. Some people use it daily, some rarely, some have only just started. The total hides all of that, and the honesty is the point of quoting both numbers rather than one. What it took was not a new AI platform or a big budget. It was making the capabilities understandable enough to trust, and a good deal of quieter work around them.
One word on security, because it is the deep question with real search volume and it deserves a real answer rather than a shrug. Access is bound to the identity provider the company already runs, and every tool enforces the same roles every other system already enforces. The agent cannot reach anything the person behind it could not reach on their own. That is a post of its own, not a paragraph, but the paragraph is true.
Where to go next
If there is one thing to take from this, it is the move, not the protocol: make the meaning travel with the capability. The protocol can standardise the connection. It cannot hand you the meaning, and that meaning has to come from the organisation itself.
Once meaning travels with the capabilities, the next question is how many to expose and when an agent is even the right shape, which is where I would send you next: scale capabilities before you scale agents.
This post is one piece of a longer argument. Production MCP: A Practitioner's Guide puts all of them in order, from understanding your data through to identity-bound deployment.
Go deeper: read the full practitioner report, The Missing Layer, or explore the mcp-metadata-demo server, an open-source extract of these patterns, since the production servers run on private business data.
