Building an MCP server for a 40-year-old industrial language

When the only person who understands your system goes on leave

The G2 platform had been running in manufacturing plants for decades. Six thousand operational rules. Forty-two thousand live data points. Sub-second response times for process control decisions. Mission-critical in the most literal sense: if it fails, the plant notices immediately.

It also ran on a proprietary language that almost no one in the world could read, write, or debug without months of specialised training.

When the sole developer who held this knowledge was unavailable, everything stopped. Not "slowed down." Stopped. No bugs fixed, no features shipped, no customer questions answered. The entire delivery roadmap was contingent on one person's availability.

This is a more common situation than organisations admit. Most teams have a G2: a system so specialised, so old, or so under-documented that knowledge has concentrated in one or two people. The usual response is to accept the risk, write a succession plan, and hope nothing breaks.

We took a different approach.

Why MCP is the right pattern for legacy knowledge problems

The obvious solution — fine-tuning a model on the documentation — has a critical weakness: the training data becomes stale, and fine-tuned models can't tell you *which page* of the manual they're drawing on, making their answers hard to verify.

Model Context Protocol (MCP) works differently. Instead of training the model on the documentation ahead of time, you give the model a live connection to the documentation at query time. The model reads the relevant section, reasons against it, and cites its source. It doesn't guess from memory — it looks it up.

This matters for legacy systems because documentation is authoritative but dense; answers are verifiable since every response includes a source reference so engineers can check the model's work; and the documentation can be updated without retraining. For a proprietary language with 40 years of documentation, this changes what's possible.

What we built

Phase 1: Documentation layer. We built an MCP server that connected Claude to the full G2 product manual library. Any engineer could now ask questions in plain English and get a sourced answer. Questions that previously required either the expert or hours of manual searching now took 30 seconds.

Phase 2: Code base interrogation. We extended the MCP layer to work against live customer code bases, not just the manuals. Engineers could ask "why is this rule firing?" or "what calls this function?" against actual G2 code. The model could explain logic, identify bottlenecks, and surface stale or redundant rules — things that previously required the expert to sit with the code and explain it.

Phase 3: Flexible deployment. Not every client has the same security posture. We designed a modular installer: the MCP server alone, or bundled with an optional local LLM for air-gapped environments, or bundled with a hosted chat interface for teams comfortable with cloud inference. Clients choose what fits their infrastructure.

Phase 4: Integration into the operator UI. The AI assistant is now embedded directly into the new operator dashboard being built in parallel. Plant operators don't switch to a separate tool; they ask questions in the same environment they work in.

What changed

During development, the team started using the system to answer questions they previously couldn't answer themselves. G2 questions that would have gone to the expert — or been left unanswered — were being resolved in real time.

That's the clearest measure of what changed: knowledge that was locked in one person's expertise became accessible to a broader team. Not replaced — the expert's judgment and experience are still irreplaceable. But the dependency on that expert for routine interrogation of the system was dramatically reduced.

The executive lesson

Every organisation has a G2.

It might be a legacy CRM, a proprietary trading system, a custom ERP built fifteen years ago by a team that has since left. The technology may still be running fine. The risk isn't technical — it's epistemic. Knowledge has concentrated, and the organisation has quietly accepted that dependency as a permanent constraint.

AI doesn't solve this by replacing the expert. It solves it by connecting others to the knowledge the expert holds — the documentation, the patterns, the logic embedded in years of accumulated code. MCP is one of the better tools for doing this precisely because it preserves auditability: you can always trace what the model saw and why it answered the way it did.

If your engineering organisation has a single point of knowledge failure, the question is not whether to address it. It's how fast.