Betrieb, Katalog und Team-Governance

Betrieb, Katalog und Team-Governance

0:00 Ein Verzeichnis sagt, dass es einen Server gibt. Nicht, dass man ihm trauen darf. Diesen Unterschied macht die offizielle MCP Registry selbst sehr deutlich — und er beschreibt zugleich die Aufgabe dieses Moduls. Es geht um das, was nach dem Bauen und Absichern kommt: den Betrieb, den Umgang mit Änderungen und die Frage, wer im Unternehmen entscheidet, welcher Server eingesetzt werden darf.

Betrieb, Katalog und Team-Governance

0:24 Vier Themen, und sie sind unterschiedlich technisch. Skalierung und Zustand ist Architektur. Resilienz ist Betrieb. Versionierung und Abkündigung ist Schnittstellendisziplin. Und der Katalog mit seiner Freigaberegel ist Organisation. Das letzte Thema ist das, was Sie am ehesten mit ins Unternehmen nehmen — und das, für das es keine technische Lösung gibt.

Skalierung und Zustand

0:47 Fangen wir mit dem angenehmsten Teil an: Die Zustandslosigkeit zahlt sich im Betrieb aus. Weil jede Anfrage alles Nötige selbst mitbringt, lässt sich ein MCP-Server ohne Sitzungsbindung über beliebig viele Instanzen verteilen. Das ist der praktische Gewinn der Entscheidung aus Modul 4. Wer trotzdem Zustand über mehrere Anfragen braucht, muss ihn explizit machen: ein Bezeichner, den der Client bei jedem Aufruf mitgibt.

1:12 Die Spezifikation merkt dazu an, dass das Protokoll selbst keinen Zustandsbegriff kennt — auf der Leitung ist ein Handle eine gewöhnliche Zeichenkette. Drei Ebenen, von kurzlebig nach langlebig. Die Anfrage trägt alles Nötige. Das Handle trägt fachlichen Zustand und ist serverseitig an den Nutzer gebunden. Und der Zwischenspeicher hält Listen mit ihrer Lebensdauer. Die mittlere Ebene ist die, die Entwurfsarbeit verlangt — die beiden anderen ergeben sich aus dem Protokoll.

1:42 Wer alles in die mittlere Ebene packt, baut sich die Sitzung wieder, die man gerade losgeworden ist. Vier Regeln, und sie stammen direkt aus den Sicherheitshinweisen der Spezifikation. Der Server prüft bei jedem Aufruf die Berechtigung am Handle. Die Bindung erfolgt über die verifizierte Identität — nicht über das, was der Client behauptet. Handles sollen zufällig, nicht erratbar und zeitlich begrenzt sein.

2:07 Und ein abgelaufenes Handle liefert einen Ausführungsfehler, der den Neuanlauf erklärt. Der letzte Punkt ist die Verbindung zu Modul 6: Auch hier entscheidet die Meldung darüber, ob der Agent sich erholt. Der erste Punkt ist der klassische Migrationsfehler: Die Lastverteilung setzt auf Sitzungsbindung, die es nicht mehr gibt.

2:27 Der zweite ist der, der zu State Handle Hijacking führt — fortlaufend nummerierte Handles. Der dritte ist ein Detail mit Wirkung: Die Lebensdauer eines Handles steht nirgends beschrieben, also weiß auch das Modell nicht, dass es Zustand anlegt, der abläuft. Und der vierte ist der Zwischenspeicher, der über Berechtigungsgrenzen hinweg ausliefert — dazu hatten wir in Modul 8 alles.

Resilienz im Betrieb

2:49 Kommen wir zum Betrieb. Und dazu, dass Agenten ein System anders belasten als Menschen. Resilienz heißt, dass ein Server bei Teilausfällen definiert reagiert statt beliebig. Vier Mittel tragen im Agentenbetrieb am meisten: Zeitgrenzen je Operation, begrenzte Wiederholungen, ein Schutzschalter vor instabilen Zielsystemen und Rate Limits je Identität.

3:12 Nichts davon ist neu — neu ist die Dringlichkeit. Was bei menschlichen Nutzern gelegentlich auffällt, tritt bei Agenten regelmäßig und in Serie auf. Jedes Mittel gegen ein konkretes Fehlerbild. Und die Fußzeile enthält die Bedingung, ohne die das dritte gefährlich wird: Wiederholungen setzen Idempotenz voraus. Ohne sie erzeugt jede Wiederholung eine zweite Wirkung — im Anliegenbuch also eine zweite Serviceanfrage.

3:38 Das ist die Verbindung zu Modul 8, und es ist der Grund, warum Idempotenz dort keine akademische Übung war. Vier Beobachtungen, die zusammen ein Bild ergeben. Ein Fehlschlag löst sofort den nächsten Versuch aus — kein Zögern, keine Kaffeepause. Eine Schleife erzeugt in Sekunden, wofür ein Team Stunden bräuchte. Ein unklarer Fehler führt zu Wiederholung statt zu Abbruch, und wir wissen aus Modul 6, wie oft Fehler unklar sind.

4:04 Und der vierte Punkt ist der, der in der Rechnung fehlt: Kosten entstehen dabei unbemerkt und schnell. OWASP führt das inzwischen als eigene Bedrohung. Der erste Punkt ist der Klassiker der verteilten Systeme: Wiederholungen ohne Wartezeit verstärken den Ausfall. Der zweite ist ein Betriebsthema, das man einmal einrichten muss: Der Schutzschalter öffnet, aber niemand erfährt davon — dann sieht die Anwendung nur, dass nichts mehr geht.

4:30 Der dritte ist der, auf den es hier ankommt: Rate Limits gelten für Menschen, nicht für Dienstidentitäten. Und der vierte ist die Mehrdeutigkeit, vor der wir in Modul 6 gewarnt haben: Bei Teilausfall kommt ein leeres Ergebnis statt eines Fehlers.

Telemetrie, Versionierung und Deprecation

4:44 Jetzt zur Frage, wie man sichtbar bleibt — und wie man Änderungen ankündigt, ohne Nutzer zu verlieren. MCP reserviert in den Metadaten die Schlüssel für die Weitergabe von Trace-Kontext nach W3C — und zwar als ausdrückliche Ausnahme von seinen eigenen Namensregeln. Die Begründung steht in der Spezifikation: Kompatibilität zu den OpenTelemetry-Konventionen für MCP.

5:07 Das ist eine kleine Entscheidung mit großer Wirkung: Ein Werkzeugaufruf fügt sich ohne Zusatzarbeit in eine bestehende Trace-Kette ein, über Systemgrenzen hinweg. Das ist der Gedanke, der in der Praxis am häufigsten fehlt. Eine geänderte Beschreibung ändert das Verhalten des Modells — das ist keine Dokumentation, das ist Verhalten.

5:28 Ein verschärftes Schema bricht bestehende Aufrufe. Neue Pflichtfelder gehören wie ein API-Bruch behandelt. Und Abkündigungen brauchen eine Frist und eine benannte Alternative. Behandeln Sie Ihren Werkzeugkatalog also wie eine öffentliche Schnittstelle, auch wenn er nur intern genutzt wird. Vier Änderungsarten mit klarem Weg. Ein neues optionales Feld geht direkt. Ein neues Pflichtfeld verlangt ein neues Werkzeug und die Abkündigung des alten.

5:55 Geänderte Bedeutung verlangt einen neuen Namen und eine Übergangszeit mit beiden. Und eine Entfernung wird angekündigt, bevor sie passiert. Die Fußzeile verweist auf das Vorbild: Die Spezifikation selbst macht es so — abgekündigte Features tragen ein Datum für den frühesten Entfall. Der erste Punkt ist der, den man nicht kommen sieht: Die Beschreibung wird verbessert, und das Verhalten ändert sich still.

6:20 Ein Wort mehr, und das Modell wählt ein anderes Werkzeug. Der zweite ist die verbreitetste Kompatibilitätsverletzung: Ein Feld wird zur Pflicht, weil es fachlich richtig ist. Der dritte ist ein Kommunikationsfehler — Abkündigungen stehen im Changelog, aber nicht dort, wo sie jemand sieht: in der Beschreibung des Werkzeugs selbst.

Katalog, Freigabe und Team-Policy

6:39 Bleibt das Thema, für das es keine technische Lösung gibt — und das über die Sicherheit Ihres Bestands mehr entscheidet als der ganze Rest. Die MCP Registry ist das offizielle zentrale Metadatenverzeichnis für öffentlich erreichbare Server. Drei Dinge sollten Sie darüber wissen. Sie befindet sich im Preview. Sie verwaltet Namensräume über DNS-Verifikation, was Herkunft belegt.

7:02 Und — das ist der entscheidende Punkt — sie delegiert das Sicherheitsscanning ausdrücklich an die Paketverzeichnisse und an nachgelagerte Aggregatoren. Sie prüft also Identität, nicht Inhalt. Vier Gründe, und der erste ist der handfeste: Private Server unterstützt das offizielle Verzeichnis gar nicht — das steht ausdrücklich in der Dokumentation.

7:24 Der zweite ist organisatorisch: Freigabeentscheidungen sind unternehmensspezifisch. Der dritte betrifft Angaben, die niemand für Sie pflegt: Herkunft, Pflegezustand, Lizenz. Und der vierte ist der, der im Vorfall zählt: Der Katalog ist die Liste, gegen die geprüft wird, wenn eine Schwachstelle bekannt wird. Fünf Schritte, und die Fußzeile nennt den, der am häufigsten übersprungen wird: Schritt drei, die Werkzeugbeschreibungen lesen — nicht nur die Liste der Namen.

7:53 Genau dort fällt Tool Poisoning auf, also versteckte Anweisungen im Beschreibungstext. Schritt vier ist ebenfalls wichtig: in isolierter Umgebung ausprobieren und die Aufrufe mitlesen. Ein Server, der beim ersten Start unerwartete Verbindungen aufbaut, hat sich damit selbst disqualifiziert. Der erste Punkt ist genau der Irrtum aus der Einleitung: Der Eintrag im Verzeichnis wird als Prüfsiegel gelesen.

8:17 Der zweite ist der Zeitfehler: Ein Server wird einmal geprüft und nie wieder. Der dritte macht das noch schlimmer — Aktualisierungen laufen automatisch und ändern Beschreibungen ungesehen. Das ist der Rug Pull: Beim Einbinden harmlos, drei Versionen später nicht mehr. Und der vierte ist ein Organisationsfehler mit Ansage: Die Freigabe erteilt, wer den Server einsetzen will.

Übung

8:40 Zum Abschluss schreiben wir auf, was gelten soll — und wer entscheidet. Zwei Dokumente. Die Betriebscheckliste hält fest, was für anliegen-mcp gilt. Die Freigaberegel hält fest, wer entscheidet, ob ein fremder Server ins Haus darf. Beide sind kurz, beide sind unspektakulär — und beide sind das, was im Ernstfall den Unterschied macht zwischen einer geordneten Reaktion und einer hektischen.

9:05 Die Checkliste nennt Rollen, Berechtigungen, Trust-Modell, Zeitgrenzen, Telemetrie und die Zuständigkeit im Störungsfall. Die Freigaberegel nennt Prüfschritte, Entscheidungsbefugnis und den Umgang mit Aktualisierungen. Und achten Sie auf den Hinweis: Die Regel muss auch den Fall abdecken, dass ein bereits freigegebener Server seine Werkzeugbeschreibungen ändert.

9:27 Das ist der Fall, den fast jede Regel vergisst — und der häufigste in der Praxis. Der erste Punkt unterscheidet ein Arbeitsdokument von einem Wunschzettel: Die Checkliste beschreibt Wünsche statt geltender Festlegungen. Der zweite ist der, der im Vorfall auffällt — die Zuständigkeit liegt bei einem Team und nicht bei Personen. Teams sind nachts nicht erreichbar.

9:48 Der dritte ist der eben genannte Wiederholungsfall. Und der vierte ist die verbreitetste Ausnahme: Für interne Server gilt die Regel nicht, weil man sich selbst vertraut. Morgen führen wir im Capstone alles zusammen.