"MCP server" sounds like plumbing. For a while we treated it that way — a piece of integration code between an AI agent and a system that already exists, useful and unremarkable.
Then we put a dashboard on it.
At SABO IT we are building our own internal MCP servers for Atlassian and Redmine. The Model Context Protocol (MCP) is an open standard that lets an AI agent call defined tools against an external system. In practice that means an agent can retrieve and work with data in Jira, Confluence or Redmine — instead of a person opening three applications to find out when a ticket last moved.
We instrumented these servers from the beginning, mostly out of habit. The first weeks of data turned out to be the interesting part.
Our Redmine MCP server has been running for about four weeks in internal use. In that time it handled roughly 1,000 successful tool calls, which produced approximately 7,100 MCP protocol messages and 1,080 backend API requests.
Two things stood out.
Around seven protocol messages per useful action. One tool call is not one exchange — it is a short conversation. Initialisation, capability negotiation, notifications and results all travel across the same layer. Part of that is deliberate: we are not simply wrapping the API, we are wrapping workflows, so one call can stand in for several steps a person would otherwise do by hand. At our current volume this costs nothing worth mentioning. The ratio, though, does not improve on its own as volume grows. It multiplies.
Roughly one backend request per tool call. We had expected the amplification to sit in backend fan-out. It sits in the protocol layer instead. That was not our assumption before we measured it — which is, in fairness, the entire reason for measuring.
A word on scale, before anyone reads more into this than it deserves: this is version 0.1.0, four weeks old, in internal use. It is not a fleet under load, and we are not going to pretend otherwise. That is precisely why the ratios matter more than the totals. Ratios describe behaviour that scales. Totals only describe Tuesday.
About 1% of HTTP requests to the Redmine server come back 405 — method not allowed, mostly GET against the MCP endpoint. No user complained. No workflow visibly failed. Our dashboard simply mentioned it, quietly, about 1,200 times.
That is the honest case for observability on this layer. Not that it validates a thesis, but that it tells you which of your assumptions were wrong while the system is still small enough that fixing them is a morning's work rather than a project.
It also changes how we prioritise. Once call volume and error rates are visible per tool, engineering effort stops being spread evenly out of politeness. A rarely used tool with slightly higher latency affects almost nobody. A frequently used tool with the same behaviour affects every agent and every workflow that touches it. Caching, retry logic, error handling — and increasingly token efficiency — go where the traffic actually is — which, so far, has never been quite where we assumed.
The second thing we are building is richer UI capability inside our MCP servers.
Ask an agent a question about Jira or Confluence data and get a chart back rather than a paragraph. It sounds like a small thing. In use it feels considerably larger, because reading a number is not the same as reading a sentence about a number.
One technical distinction matters here, because it is easy to misread: we do not render the UI components of the connected applications. We use the MCP protocol to transfer UI resources through MCP Apps. The interface is generated for the answer — not a reproduction of Jira's or Redmine's own screens.
This is the part of our work that points furthest ahead. Interacting with enterprise software has meant navigating menus until you arrive at the data. Some of that may be replaced by stating what you need and receiving both the data and a sensible way to read it.
It is also, inevitably, more protocol traffic. Which brings us back to the ratio.
In a production agentic system, performance is a property of the whole chain:
AI model → agent → MCP layer → tools → enterprise systems
Almost all of the conversation concentrates on the first element. Which model reasons better, which is faster, which has the larger context window. Real questions — about one link.
If an agent needs Redmine to finish a task, the quality of that exchange is part of the answer. A capable model cannot compensate indefinitely for a slow or unreliable tool layer. The layer's latency becomes the user's latency. Its errors propagate into workflows. Its reliability sets the ceiling on the agent's reliability. The model gets the attention; the layer underneath gets the blame.
And the consequence is not really technical. When an agent fails often enough, people stop using it and go back to the manual route they trust. The investment is not degraded at that point. It is simply unused.
Our servers connect to Atlassian and Redmine — development and project systems, comparatively forgiving ones. The architectural question is identical wherever the systems behind the agent are operational: ERP, MES, maintenance, quality management.
In industrial environments the requirements get stricter, not looser. Software has to fit what already exists and stay dependable across life cycles measured in years. An integration layer treated as disposable code does not survive that kind of exposure.
So we now treat MCP servers the way we treat any other reliability-critical component: instrumented, measured, versioned and owned by someone.
A proof of concept asks one question. Can the agent do the task?
A production system asks the awkward ones. How reliably? How many tool calls does it need? Where does latency collect? Which integrations generate the most errors? What happens when a backend is down? Which tool becomes the bottleneck first?
These questions attract less attention than model benchmarks. They decide whether an agent stays a convincing demonstration or becomes something a business can depend on.
Building the agent is one part of the engineering work. Making it work reliably against real systems is where production engineering starts.
That is what Knowledge in Action means for us in practice. Not adding AI because it is available, but engineering it into real systems and processes so that it works where the actual work happens.
