Model Context Protocol (MCP) in Manufacturing Model Context Protocol (MCP) in der Fertigung

What MCP Actually Is Was MCP wirklich ist

Model Context Protocol is not another API standard. It is not REST. It is not GraphQL. It is a protocol that lets an AI agent connect to an external server, ask “what tools do you have?”, and get a typed schema back. The agent can then call those tools with validated parameters and receive structured JSON responses. Model Context Protocol ist kein weiterer API-Standard. Es ist nicht REST. Es ist nicht GraphQL. Es ist ein Protokoll, das einem KI-Agenten ermöglicht, sich mit einem externen Server zu verbinden, zu fragen „welche Tools hast du?“ und ein typisiertes Schema zurückzubekommen. Der Agent kann dann diese Tools mit validierten Parametern aufrufen und strukturierte JSON-Antworten erhalten.

The key difference from a traditional API: discovery is built in. An agent connects to an MCP server and calls listTools(). It gets back a list of available operations with their parameter schemas and descriptions. The agent can then decide which tools to call based on the task at hand. No API docs to read, no endpoints to memorize, no versioning headaches. Der zentrale Unterschied zu einer traditionellen API: Discovery ist eingebaut. Ein Agent verbindet sich mit einem MCP-Server und ruft listTools() auf. Er bekommt eine Liste verfügbarer Operationen mit deren Parameter-Schemas und Beschreibungen zurück. Der Agent kann dann entscheiden, welche Tools er basierend auf der aktuellen Aufgabe aufruft. Keine API-Docs lesen, keine Endpoints merken, keine Versionierungsprobleme.

Why Manufacturing Needs It Warum die Fertigung das braucht

A typical discrete manufacturing plant runs at least four core systems: ERP for orders and planning, MES for production execution, QMS for quality management, and WMS for warehouse and materials. Each system has its own database, its own API (if it has one), its own schema, and its own authentication. Some expose REST endpoints. Some only offer ODBC. Some have no API at all — you query the database directly. Ein typischer Fertigungsbetrieb betreibt mindestens vier Kernsysteme: ERP für Aufträge und Planung, MES für die Produktionsausführung, QMS für Qualitätsmanagement und WMS für Lager und Material. Jedes System hat seine eigene Datenbank, seine eigene API (falls vorhanden), sein eigenes Schema und seine eigene Authentifizierung. Manche bieten REST-Endpoints. Manche nur ODBC. Manche haben überhaupt keine API — man fragt die Datenbank direkt ab.

The math is simple: without MCP, adding a new agent means writing 4 new integrations. With MCP, adding a new agent means zero integration work — it just connects to the existing servers and discovers their tools. This is what makes scaling from 1 agent to 10 agents practical instead of exponential. Die Rechnung ist einfach: Ohne MCP bedeutet ein neuer Agent 4 neue Integrationen schreiben. Mit MCP bedeutet ein neuer Agent null Integrationsaufwand — er verbindet sich einfach mit den bestehenden Servern und entdeckt deren Tools. Das macht die Skalierung von 1 auf 10 Agenten praktikabel statt exponentiell.

Our Architecture: 4 MCP Servers on Kubernetes Unsere Architektur: 4 MCP-Server auf Kubernetes

We run 4 MCP servers in a Kubernetes namespace called demo. Each server is a Node.js process with one or more PostgreSQL connection pools. Here is what they expose: Wir betreiben 4 MCP-Server in einem Kubernetes-Namespace namens demo. Jeder Server ist ein Node.js-Prozess mit einem oder mehreren PostgreSQL-Connection-Pools. Das bieten sie an:

Each server exposes 5–15 tools. Agents don’t know which database they’re talking to. They don’t know if data comes from PostgreSQL, SAP, or a flat file. They call tools like get_oee_hourly({machine_id: "SMD-3"}) and get structured data back. The SQL, connection pooling, parameter validation, and error handling all live inside the MCP server. Jeder Server bietet 5–15 Tools an. Agenten wissen nicht, mit welcher Datenbank sie sprechen. Sie wissen nicht, ob die Daten aus PostgreSQL, SAP oder einer Flatfile kommen. Sie rufen Tools auf wie get_oee_hourly({machine_id: "SMD-3"}) und bekommen strukturierte Daten zurück. SQL, Connection Pooling, Parametervalidierung und Fehlerbehandlung leben alle im MCP-Server.

One subtlety worth noting: the QMS server maintains two database pools — qmsPool and erpPool. Quality analysis often requires cross-referencing quality data with production order data. Rather than making the agent call two separate servers, the QMS server handles the join internally. The agent doesn’t know or care. Ein Detail, das erwähnenswert ist: Der QMS-Server unterhält zwei Datenbank-Pools — qmsPool und erpPool. Qualitätsanalysen erfordern oft die Verknüpfung von Qualitätsdaten mit Fertigungsauftragsdaten. Statt den Agenten zwei separate Server aufrufen zu lassen, erledigt der QMS-Server den Join intern. Der Agent weiß nichts davon und muss sich nicht darum kümmern.

How an Agent Query Works Wie eine Agenten-Abfrage funktioniert

[
  { name: "get_oee_hourly",
    params: { machine_id: "string", date: "string?" },
    returns: "{ machine_id, hour, oee, availability, performance, quality }" },
  { name: "get_downtime_events",
    params: { machine_id: "string", from: "string", to: "string" },
    returns: "{ events: [{ start, end, duration_hours, description }] }" },
  ...
]

get_oee_hourly({ machine_id: "SMD-3", date: "2026-02-14" })

{
  machine_id: "SMD-3",
  date: "2026-02-14",
  hours: [
    { hour: 6, oee: 0.82, availability: 0.95, performance: 0.91, quality: 0.95 },
    { hour: 7, oee: 0.61, availability: 0.72, performance: 0.89, quality: 0.95 },
    ...
  ]
}

Parallel Queries: The Performance Trick Parallele Abfragen: Der Performance-Trick

Here is the detail that makes the architecture fast: agents send requests to all 4 MCP servers simultaneously. A typical morning analysis needs OEE data (MES), open orders (ERP), quality metrics (QMS), and material availability (WMS). Sequentially, that is 4 × 200ms = 800ms. In parallel, it is just 200ms — the time of the slowest server. Hier ist das Detail, das die Architektur schnell macht: Agenten senden Anfragen an alle 4 MCP-Server gleichzeitig. Eine typische Morgenanalyse braucht OEE-Daten (MES), offene Aufträge (ERP), Qualitätsmetriken (QMS) und Materialverfügbarkeit (WMS). Sequentiell wären das 4 × 200ms = 800ms. Parallel sind es nur 200ms — die Zeit des langsamsten Servers.

// Parallel MCP calls — all fire at once
const [oeeData, orders, quality, materials] = await Promise.all([
  mcpCall('oee-db-mcp',    'get_oee_hourly',        { date: today }),
  mcpCall('erp-db-mcp',    'get_open_orders',        { status: 'active' }),
  mcpCall('qms-db-mcp',    'get_quality_summary',    { date: today }),
  mcpCall('factory-db-mcp','get_material_shortages',  {})
]);
// Total time: ~200ms (slowest server), not ~800ms (sum)// Parallele MCP-Calls — alle gleichzeitig
const [oeeData, orders, quality, materials] = await Promise.all([
  mcpCall('oee-db-mcp',    'get_oee_hourly',        { date: today }),
  mcpCall('erp-db-mcp',    'get_open_orders',        { status: 'active' }),
  mcpCall('qms-db-mcp',    'get_quality_summary',    { date: today }),
  mcpCall('factory-db-mcp','get_material_shortages',  {})
]);
// Gesamtzeit: ~200ms (langsamster Server), nicht ~800ms (Summe)

This is why 6 agents can analyze a full factory in under 3 minutes. Each agent fires parallel MCP calls, gets all data in ~200ms, then spends the remaining time on LLM analysis and multi-agent debate. The data loading phase is negligible compared to the reasoning phase. Deshalb können 6 Agenten eine komplette Fabrik in unter 3 Minuten analysieren. Jeder Agent feuert parallele MCP-Calls, bekommt alle Daten in ~200ms, und verbringt dann die restliche Zeit mit LLM-Analyse und Multi-Agenten-Debatte. Die Daten-Ladephase ist vernachlässigbar im Vergleich zur Reasoning-Phase.

It also scales horizontally. Need to add a 5th system (e.g., a CMMS for maintenance planning)? Deploy one more MCP server. All existing agents can discover and use its tools immediately. No code changes in the agents. For a deeper look at the full technology stack, see our technology page. Es skaliert auch horizontal. Braucht man ein 5. System (z.B. ein CMMS für Wartungsplanung)? Einen weiteren MCP-Server deployen. Alle bestehenden Agenten können seine Tools sofort entdecken und nutzen. Keine Code-Änderungen in den Agenten. Für einen tieferen Blick auf den gesamten Technologie-Stack, siehe unsere Technologie-Seite.

Lessons Learned from Production Lessons Learned aus der Produktion

Running MCP servers against real factory databases has taught us things that no documentation covers. Here are the ones that cost us the most debugging time: MCP-Server gegen echte Fabrik-Datenbanken zu betreiben hat uns Dinge gelehrt, die keine Dokumentation abdeckt. Hier sind die, die uns die meiste Debugging-Zeit gekostet haben:

PostgreSQL NUMERIC returns strings PostgreSQL NUMERIC liefert Strings

The node-pg driver returns PostgreSQL NUMERIC columns as JavaScript strings, not numbers. This means oee_value comes back as "0.782", not 0.782. If your agent tries to do math on it or compare it to a threshold, you get string concatenation instead of addition. The fix: always Number() cast before .toFixed() or any arithmetic. We burned two days on this before adding a project-wide lint rule. Der node-pg-Treiber liefert PostgreSQL-NUMERIC-Spalten als JavaScript-Strings, nicht als Zahlen. Das bedeutet, oee_value kommt als "0.782" zurück, nicht 0.782. Wenn der Agent damit rechnen oder es mit einem Schwellenwert vergleichen will, erhält man String-Konkatenation statt Addition. Die Lösung: immer Number() casten vor .toFixed() oder jeder Arithmetik. Wir haben zwei Tage damit verloren, bevor wir eine projektweite Lint-Regel hinzugefügt haben.

Column name mismatches are silent killers Spaltenname-Mismatches sind stille Killer

When you write a tool handler, you name the fields in your response object. When you write the SQL, you use the actual column names. These can drift apart. The handler might return short_text while the DB column is called description. The tool returns undefined for that field, the agent silently ignores it, and you don’t notice until someone asks “why are there no descriptions in the quality notifications?”. Our fix: validate handler output against information_schema.columns during CI. Wenn man einen Tool-Handler schreibt, benennt man die Felder im Response-Objekt. Wenn man SQL schreibt, verwendet man die tatsächlichen Spaltennamen. Diese können auseinanderdriften. Der Handler liefert vielleicht short_text, während die DB-Spalte description heißt. Das Tool liefert undefined für dieses Feld, der Agent ignoriert es stillschweigend, und man merkt es nicht, bis jemand fragt „warum gibt es keine Beschreibungen in den Qualitätsmeldungen?“. Unser Fix: Handler-Output gegen information_schema.columns in der CI validieren.

Large tables need LIMIT — always Große Tabellen brauchen LIMIT — immer

Our qms_notifications table has 200,000+ rows. An early version of the get_open_notifications tool had no LIMIT clause. An agent called it, the server tried to serialize 200k rows into JSON, and the MCP server OOM’d. The agent then retried. Three times. Each retry consumed more memory on the Kubernetes pod until it got evicted. Every tool that touches a table over 10k rows now has a mandatory LIMIT parameter with a default of 100. Unsere qms_notifications-Tabelle hat über 200.000 Zeilen. Eine frühe Version des get_open_notifications-Tools hatte keine LIMIT-Klausel. Ein Agent rief es auf, der Server versuchte 200k Zeilen in JSON zu serialisieren, und der MCP-Server lief in einen OOM. Der Agent versuchte es erneut. Dreimal. Jeder Retry verbrauchte mehr Speicher auf dem Kubernetes-Pod, bis er evicted wurde. Jedes Tool, das eine Tabelle mit über 10k Zeilen anspricht, hat jetzt einen obligatorischen LIMIT-Parameter mit einem Default von 100.

Cross-pool queries need careful placement Cross-Pool-Abfragen brauchen sorgfältige Platzierung

Some analysis requires data from two databases in a single tool call — e.g., correlating quality defects (QMS database) with production order details (ERP database). You cannot do this from the ERP server because it only has an ERP pool. The QMS server has both pools. So the tool lives on the QMS server, even though it partially queries ERP data. This is a routing decision that the agent never sees, but getting it wrong means missing data or failed queries. Manche Analysen erfordern Daten aus zwei Datenbanken in einem einzigen Tool-Call — z.B. die Korrelation von Qualitätsdefekten (QMS-Datenbank) mit Fertigungsauftragsdetails (ERP-Datenbank). Das geht nicht vom ERP-Server, weil der nur einen ERP-Pool hat. Der QMS-Server hat beide Pools. Also lebt das Tool auf dem QMS-Server, obwohl es teilweise ERP-Daten abfragt. Das ist eine Routing-Entscheidung, die der Agent nie sieht, aber wenn sie falsch ist, fehlen Daten oder Abfragen schlagen fehl.