Einen eigenen MCP-Server bauen · und ihn so zuschneiden, dass er im Betrieb hält

Für die gängigen Systeme gibt es fertige MCP-Dienste. Interessant wird es bei dem einen System, das es nur bei Ihnen gibt: die Fachanwendung aus den späten Neunzigern, die Datenbank hinter der Produktionssteuerung, der Dienst, den ein Mitarbeiter vor acht Jahren geschrieben hat und der seitdem läuft. Für diese Fälle baut man einen eigenen Server.

Dieser Beitrag zeigt, wie das geht, und er beginnt mit der unbequemen Frage, ob man es überhaupt tun sollte.

Erst die Frage, dann der Code

Wir sind kein Softwarehersteller. Wir bauen Spezialsoftware nur dann, wenn sich das wirklich lohnt, und derselbe Maßstab gilt für einen Konnektor. Drei Bedingungen sollten erfüllt sein, bevor jemand anfängt.

• Das System hat eine Schnittstelle, die stabil genug ist, um darauf aufzusetzen. Ein Bildschirmabgriff auf eine Oberfläche ist kein Anschluss, sondern eine Verabredung zum Ausfall.
• Es gibt mindestens zwei Abläufe, die davon profitieren. Für genau einen Ablauf ist ein Ausdruck aus dem System oft die ehrlichere Lösung.
• Jemand ist bereit, den Dienst zu betreiben. Ein Konnektor ohne Zuständigkeit ist Schulden, die erst beim nächsten Versionswechsel fällig werden.

Fehlt eine der drei Bedingungen, ist die Antwort nicht zwingend Nein, aber sie ist erst einmal Warten.

Was ein MCP-Server tatsächlich ist

Ein MCP-Server ist ein Prozess, der Nachrichten nach JSON-RPC 2.0 entgegennimmt und beantwortet. Mehr nicht. Er läuft entweder als lokaler Prozess, der über die Standardein- und -ausgabe spricht, oder als Dienst über HTTP. Die maßgebliche Beschreibung steht in der Spezifikation des Model Context Protocol.

Die Beispiele hier zeigen das Protokoll auf der Leitung und keine bestimmte Bibliotheksfassung. Das ist Absicht: Bibliotheken ändern ihre Aufrufe, das Protokoll bleibt. Wer die Nachrichten versteht, kann jede Bibliothek benutzen und im Zweifel ohne sie auskommen.

Der erste Austausch nach dem Verbindungsaufbau ist immer derselbe: Der Klient fragt, welche Werkzeuge es gibt.

{ "jsonrpc": "2.0", "id": 1, "method": "tools/list" }

Die Antwort ist die eigentliche Arbeit. Sie beschreibt jedes Werkzeug so, dass ein Modell allein aus dieser Beschreibung entscheiden kann, ob und wie es das Werkzeug einsetzt.

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "tools": [
      {
        "name": "auftrag_lesen",
        "description": "Liest einen Fertigungsauftrag anhand seiner Nummer. Gibt Status, Termin und Stückzahl zurück. Keine Preise, keine Personendaten.",
        "inputSchema": {
          "type": "object",
          "properties": {
            "auftragsnummer": {
              "type": "string",
              "description": "Sechsstellige Nummer, Format A-12345"
            }
          },
          "required": ["auftragsnummer"]
        }
      }
    ]
  }
}

Diese Beschreibung ist kein Kommentar für Menschen. Sie ist die Anleitung, nach der das Modell handelt. Steht dort etwas Unklares, wird das Werkzeug falsch oder gar nicht benutzt, und die Ursache sucht man anschließend im Modell, obwohl sie im Text steht.

Der Aufruf selbst ist dann unspektakulär.

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "auftrag_lesen",
    "arguments": { "auftragsnummer": "A-41207" }
  }
}

{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "content": [
      {
        "type": "text",
        "text": "Auftrag A-41207: Status in Fertigung, Termin 2026-08-21, Stückzahl 400."
      }
    ],
    "isError": false
  }
}

Fünf Regeln für den Zuschnitt

Über die Qualität eines Anschlusses entscheidet nicht die Programmiersprache, sondern der Zuschnitt der Werkzeuge. Fünf Regeln haben sich bewährt.

• Ein Werkzeug, eine Aufgabe. Ein Werkzeug mit einem Parameter, der zwischen sieben Betriebsarten umschaltet, ist keine Vereinfachung, sondern eine Fehlerquelle mit sieben Ausprägungen.
• Lesen und Schreiben trennen. Wer beides in einem Werkzeug zusammenfasst, kann Lesezugriff nicht mehr ohne Schreibzugriff vergeben.
• Die Beschreibung sagt, was das Werkzeug nicht tut. Diese Angabe ist wertvoller als jede Aufzählung dessen, was es tut, weil sie Fehlgriffe verhindert.
• Der Rückgabewert ist für einen Leser gedacht. Ein roher Datenbankauszug mit dreißig Spalten kostet Kontext und liefert weniger Verständnis als drei Sätze.
• Fehler werden benannt, nicht verschluckt. Eine leere Antwort deutet ein Modell als Abwesenheit von Daten, und dann erfindet es welche.

Rechte, Protokoll und der Weg zurück

Drei Dinge gehören in den Dienst und nicht in die Aufrufschicht darüber, weil sie sonst umgangen werden können.

Erstens die Rechte. Der Dienst handelt im Namen eines Kontos und darf nur das, was dieses Konto darf. Ein technisches Sammelkonto mit Vollzugriff ist beim ersten Prüfungstermin das Ende der Einführung.

Zweitens die Protokollierung. Zeitpunkt, Konto, Werkzeug, Parameter und Ergebnis werden festgehalten, der Inhalt der Daten nicht. Ein Protokoll, das Inhalte mitschreibt, verlagert das Datenschutzproblem nur an eine andere Stelle.

Drittens der Weg zurück. Jede Schreiboperation braucht eine Entsprechung, die sie rückgängig macht, oder eine Freigabe durch einen Menschen, bevor sie ausgeführt wird. Welche der beiden Varianten richtig ist, entscheidet der Fachbereich und nicht die Entwicklung.

Testen, bevor ein Modell drankommt

Ein MCP-Server lässt sich vollständig ohne Modell prüfen. Die Nachrichten sind Text, der Prozess liest von der Standardeingabe, und damit ist jeder Aufruf ein wiederholbarer Test.

echo '{"jsonrpc":"2.0","id":1,"method":"tools/list"}' \
  | node ./mcp-fertigung/server.js

Wir empfehlen drei Prüfungen vor der ersten Freigabe: jedes Werkzeug einmal mit gültigen Parametern, einmal mit ungültigen, und einmal mit einem Konto, das keine Berechtigung hat. Die dritte ist die wichtigste, und sie wird am häufigsten vergessen.

Was wir nicht empfehlen

• Ein Werkzeug, das beliebige Datenbankabfragen entgegennimmt. Es ist schnell gebaut, und es hebt jede Rechtevergabe auf, die darunter liegt.
• Einen Dienst, der Anmeldedaten für ein Fachsystem selbst hält. Sie gehören in die Geheimnisverwaltung, nicht in die Konfiguration des Konnektors.
• Werkzeuge, die vom Modell einen Freitext erwarten und ihn ungeprüft weiterreichen. Was hinter der Schnittstelle liegt, kann diesen Text nicht einordnen.
• Einen eigenen Dienst für ein System, für das ein gepflegter Konnektor existiert. Der eigene ist am Anfang besser und nach zwei Jahren älter.

Wo es weitergeht

Welche Systeme bereits fertig angebunden sind, steht auf der Seite zu den MCP-Konnektoren. Wie sich der Anschluss in die Gesamtarchitektur einfügt, beschreibt der Beitrag über CRM und ERP. Wer den Zuschnitt eigener Fähigkeiten und Werkzeuge in einer Woche lernen will statt in einem Quartal, findet in der Akademie den zweitägigen Entwicklerkurs.