MCP-Server im Eigenbetrieb: Agenten mit eigenem Wissen füttern
Coding-Agenten sind so gut wie ihr Kontext. MCP — das Model Context Protocol — ist die standardisierte Schnittstelle, über die Agenten Werkzeuge und Wissen beziehen. Die öffentlichen MCP-Server sind nützlich. Die selbstgebauten, die auf eigene Systeme zeigen, sind strategisch.
Was ein MCP-Server tut
Ein MCP-Server ist ein kleiner Dienst, der Ressourcen (Daten) und Tools (Aktionen) bereitstellt. Der Agent — Claude Code, Codex, oder ein eigener — spricht mit ihm über JSON-RPC.
Agent ⟷ MCP-Client ⟷ MCP-Server ⟷ Interne Systeme
Das Protokoll ist simpel. Die Intelligenz steckt darin, was der Server bereitstellt.
Unsere MCP-Server
Grounded Docs. Der Server, den wir am meisten nutzen. Er liest die Dokumentationen unserer eingesetzten Software — Stalwart, Zammad, Qdrant, vLLM — und stellt sie dem Agenten als semantisch durchsuchbare Ressource zur Verfügung. Der Agent muss nicht raten, welche Konfigurationsoption es gibt. Er schlägt nach.
ERP-Winline-Connector. Ein MCP-Server, der Lesezugriff auf unser ERP hat: Kundenstamm, offene Posten, Lagerbestände. Der Agent kann damit Code generieren, der auf echten Datenstrukturen basiert — nicht auf erfundenen Beispieltabellen.
Translogica-Status. Transportaufträge, Sendungsverfolgung, aktuelle Positionen. Der MCP-Server liefert sie dem Agenten, wenn er Workflow-Code für die Logistik schreibt.
Bauen: kein Hexenwerk
Ein MCP-Server ist in Python überschaubar:
from mcp.server import Server, stdio_server
from mcp.types import Tool, TextContent
server = Server("erp-connector")
@server.list_tools()
async def list_tools():
return [Tool(name="get_offene_posten", description="Offene Posten eines Kunden abfragen", inputSchema={...})]
@server.call_tool()
async def call_tool(name, arguments):
if name == "get_offene_posten":
kdnr = arguments["kundennummer"]
daten = winline_db.query(f"SELECT ... WHERE kdnr = ?", kdnr)
return [TextContent(type="text", text=str(daten))]
Der Server läuft als Prozess, der Agent verbindet sich beim Start. Keine Firewall-Freischaltung, kein exponierter Port — die Kommunikation läuft über stdin/stdout.
Sicherheit: Das Prinzip der minimalen Rechte
Ein MCP-Server bekommt nur das, was er braucht. Der ERP-Connector hat Lesezugriff auf ausgewählte Views — keine Schreibrechte, kein Direktzugriff auf die Produktivdatenbank. Der Agent kann abfragen, nicht verändern.
Fazit
Öffentliche MCP-Server sind gut. Selbstgebaute sind der Unterschied zwischen einem Agenten, der generischen Code produziert, und einem, der Ihren Betrieb versteht. Die Investition ist ein Nachmittag pro System — und zahlt sich in jedem weiteren Coding-Task aus.
Wie viel Aufwand ist es, einen eigenen MCP-Server zu bauen?+
Überschaubar. Ein MCP-Server ist ein kleiner Dienst, der Ressourcen und Werkzeuge über JSON-RPC bereitstellt und in Python mit wenigen Zeilen geschrieben ist. Er läuft als lokaler Prozess, der Agent verbindet sich beim Start über stdin/stdout — ohne Firewall-Freischaltung oder exponierten Port. Pro angeschlossenem System rechnen wir mit einem Nachmittag, und er zahlt sich in jedem weiteren Coding-Task aus.
Wie wird verhindert, dass ein Agent unsere Geschäftsdaten verändert?+
Über das Prinzip der minimalen Rechte. Der ERP-Connector erhält ausschließlich Lesezugriff auf ausgewählte Views — keine Schreibrechte und kein Direktzugriff auf die Produktivdatenbank. Der Agent kann echte Datenstrukturen abfragen, um realitätsnahen Code zu generieren, aber nichts verändern. So bleibt die Steuerung über schreibende Aktionen stets beim Menschen und damit außerhalb des Modells.
Warum eigene MCP-Server statt nur der öffentlichen?+
Öffentliche Server sind nützlich, aber strategisch wertvoll sind die, die auf die eigenen Systeme zeigen — interne Dokumentation, ERP-Daten oder Transportstatus. Sie sind der Unterschied zwischen einem Agenten, der generischen Code produziert, und einem, der den Betrieb versteht. Der Agent schlägt nach statt zu raten, ob eine Konfigurationsoption existiert, und arbeitet mit echten Datenstrukturen statt erfundenen Beispielen.