MCP-Server entwickeln und betreiben.
Das Model Context Protocol ist die Steckdose, über die ein KI-Agent an Ihre Systeme kommt. Einen Server dafür zu schreiben, dauert einen Nachmittag. Einen zu schreiben, der in einem Konzern in Betrieb gehen darf, dauert länger — und scheitert selten an der Technik.
Was wir dort tun
- Werkzeuge entlang der Fachdomäne schneiden statt die vorhandene Schnittstelle eins zu eins durchzureichen
- Betrieb über Streamable HTTP hinter dem üblichen Lastverteiler, statt einen Prozess je Benutzer über stdio zu starten
- Anbindung an die vorhandene Anmeldung: OAuth mit Ressourcenkennung, Weitergabe der Identität des Aufrufers bis in das Zielsystem
- Rechteschnitt, abgestufte Sichtbarkeit und ein Protokoll, aus dem hinterher hervorgeht, wer was ausgelöst hat
- Mehrschrittige Operationen als wiederanlauffähige Abläufe, damit ein Abbruch keinen halben Zustand hinterlässt
- Abnahme gegen ausführbare Szenarien — für einen Server, den eine Maschine bedient, ist das die einzige Prüfung, die etwas aussagt
- Mitziehen bei Protokollwechseln, ohne dass die bestehenden Aufrufer stehenbleiben
Warum der Werkzeugschnitt das Ganze entscheidet
Der häufigste Entwurf ist der naheliegende: für jeden Endpunkt des Bestandssystems ein Werkzeug. Das ergibt achtzig Werkzeuge, von denen das Modell keines sicher auswählt, und eine Beschreibung, die jeden Aufruf teurer macht als die Arbeit, die er erledigt.
Brauchbar wird ein Server erst, wenn seine Werkzeuge das abbilden, was ein Mensch im Fachbereich als eine Handlung bezeichnen würde — mit einer Beschreibung, die einen Fehlgriff unwahrscheinlich macht, und einer Antwort, die das Modell nicht erst interpretieren muss.
Das ist eine Frage an die Fachdomäne, nicht an das Protokoll. Sie fällt vor der ersten Zeile Code und lässt sich später nur noch teuer korrigieren.
Ein Werkzeugverzeichnis ist eine Eingabe, kein Vertrag.
Die Beschreibung eines Werkzeugs landet im Kontext des Modells. Wer sie schreibt, schreibt damit an der Anweisung mit, die das Modell befolgt — und das gilt auch für jeden anderen Server, der in derselben Sitzung eingebunden ist.
-
Vergiftete Werkzeugbeschreibungen
Eine Beschreibung, die neben der eigentlichen Auskunft eine Anweisung enthält, wird vom Modell gelesen wie jede andere Anweisung. Sichtbar ist sie für den Benutzer nicht: Er sieht den Namen des Werkzeugs, nicht seinen Beipackzettel.
-
Nachträglich geänderte Verzeichnisse
Ein Server darf sein Werkzeugverzeichnis ändern, nachdem der Benutzer ihm einmal zugestimmt hat. Wer bei der Freigabe geprüft hat, hat das geprüft, was damals dastand.
-
Übergriffe zwischen Servern
Mehrere Server teilen sich einen Kontext. Der eine kann beschreiben, wie mit den Werkzeugen des anderen umzugehen sei — und Daten aus einem internen System in einen Aufruf nach außen lenken.
-
Verwechselte Empfänger
Ein Zugangsmerkmal, das für einen Server ausgestellt wurde und bei einem anderen vorgelegt wird, ist der ältere Bruder desselben Problems. Die Gegenmaßnahme steht im Protokoll und wird trotzdem regelmäßig übersprungen.
Was die Fassung vom 28. Juli 2026 an bestehenden Servern bricht
Die aktuelle Protokollfassung macht den Kern zustandslos. Der einleitende Handshake und die Sitzungskennung im HTTP-Kopf entfallen; was ein Server bisher einmal ausgehandelt und danach vorausgesetzt hat, steht jetzt in jeder einzelnen Anfrage.
Für einen Server, der Sitzungszustand hält, ist das kein Feinschliff, sondern eine Umstellung des Aufbaus. Umgekehrt fällt damit die Anforderung weg, die den Betrieb bisher unangenehm gemacht hat: Ohne Sitzungsbindung läuft ein Server hinter jedem gewöhnlichen Lastverteiler und skaliert auf null.
Dazu kommen Kernfunktionen, die in Erweiterungen ausgelagert wurden und eine Übergangsfrist haben. Wer sie heute benutzt, hat einen Termin, an dem er sie nicht mehr benutzt — die Frage ist nur, ob er ihn selbst setzt.
Woran sich das nachlesen lässt
Wir schreiben MCP-Server nicht nur für Kunden. Der Server für den Zugriff auf Postfächer ist quelloffen und zeigt an einem vollständigen Beispiel, was gemeint ist: sieben Sichtbarkeitsstufen statt eines Alles-oder-nichts, kontenübergreifende Verschiebungen als wiederanlauffähiger Ablauf, ein Protokoll als Hash-Kette, 29 dokumentierte Architekturentscheidungen und 20 ausdrücklich benannte Grenzen.
Die Grenzen sind der interessantere Teil. Ein Server, dessen Beschreibung nur aufzählt, was er kann, verschweigt genau die Information, die vor der Einführung gebraucht wird.
Ein Anruf reicht, um zu klären, ob es passt.
Kein Formular mit zwölf Pflichtfeldern, keine Rückrufkette über einen Vertrieb. Sie schildern den Fall, wir sagen Ihnen, ob wir der Richtige dafür sind — auch dann, wenn die Antwort nein lautet.