# Abschluss: einen MCP-Server von Entwurf bis Betrieb verantworten

> Die Entscheidungen des gesamten Pfades an einem durchgehenden Fall zusammenführen — Primitivenwahl, Vertrauensgrenzen, Reihenfolge der Absicherung und die Diagnose eines Vorfalls im Regelbetrieb.

Track: [MCP Engineering](https://physar.tech/learn/mcp-engineering)  
Kanonische Fassung: https://physar.tech/learn/mcp-engineering/mcp-capstone  
Stand: 2026-09-05  
Interaktiver Teil: 8 Checks (nur im Browser)

## Abschluss: die Entscheidungen zusammensetzen

### Der durchgehende Fall

Ein Versicherer will Schadenssachbearbeitung mit einem Agenten unterstützen. Der Agent soll Schadensakten lesen, Kundenkorrespondenz auswerten, Sachverständigenberichte anfordern und Teilzahlungen bis 2.000 Euro freigeben. Genutzt wird das von 250 Sachbearbeitenden, die unterschiedliche Zuständigkeiten haben. Dieser Fall zieht sich durch alle Aufgaben dieses Moduls.

Die Zielarchitektur nutzt einen zentral betriebenen HTTP-MCP-Server vor einem älteren Schadenssystem und mehreren externen Gutachterdiensten. Der Host verbindet zusätzlich einen Dokumentenserver für eingehende E-Mails. Damit entstehen alle entscheidenden Übergänge: Endnutzeridentität wird delegiert, vertrauliche Daten fließen in Modellkontext, untrusted Korrespondenz beeinflusst Planung, und wirkende Tools greifen auf Zahlung und externe Kommunikation zu. Kein einzelnes Modul kann diese Komposition allein absichern.

Das Capstone verlangt deshalb eine begründete Reihenfolge. Zuerst werden Fachwirkung, Daten und Identitäten kartiert. Dann entstehen enge Capability-Verträge und durchsetzbare Policies. Erst danach folgen Autorisierungsflow, Implementierung, Telemetrie, Tests und begrenzter Rollout. Ein später Dialog kann eine fehlende Objektberechtigung nicht reparieren; ein perfekter Trace verhindert keine falsche Zahlung. Jede Kontrolle muss vor der Wirkung an ihrer zuständigen Grenze greifen.

> **Arbeitsweise:** Lies jede Aufgabe als Architekturreview: Benenne Schutzgut, Angreifer oder Fehler, durchsetzende Komponente, verbleibendes Risiko und messbaren Nachweis.

> **Worum es hier geht:** Keine neuen Konzepte — die Aufgaben verlangen, die bereits gelernten Achsen gleichzeitig anzuwenden und ihre Konflikte aufzulösen. Genau das unterscheidet Wissen von Urteil.

### Die Achsen, die hier zusammenlaufen

|  |  |
| --- | --- |
| Vertrag | Welche Fähigkeit wird Tool, welche Resource, welche Prompt-Vorlage — und wie eng ist sie geschnitten? |
| Identität | Wessen Rechte gelten beim Zugriff auf eine Akte, und woher kommt die Zuständigkeit? |
| Wirkungsgrenze | Was darf eine Modellentscheidung allein auslösen, was braucht eine Freigabe? |
| Betrieb | Wie wird ein Rollout begrenzt, wie ein Vorfall rekonstruiert, wie ein Ausfall isoliert? |

_[Abbildung: Der Fall berührt alle Grenzen des Pfades gleichzeitig — jede verlangt eine eigene, benannte Antwort.]_

Ergänze zwei weitere Achsen. **Protokollsemantik** bestimmt stateless Request-Metadaten, MRTR, Pagination, Caching, Subscriptions und Cancellation. **Lieferkette** verbindet Herausgeber, Artefaktdigest, Konfiguration, Capability-Diff und Widerruf. Diese Achsen schneiden die vier fachlichen Achsen: Ein neues Serverrelease kann ein zusätzliches Zahlungstool veröffentlichen; Discovery macht es sichtbar, aber erst Host-Policy darf es aktivieren. Ein Cache kann schnell sein und zugleich eine fremde Akte ausliefern, wenn Identität fehlt.

Bewerte Entscheidungen nicht isoliert nach ihrem lokalen Vorteil. Ein universelles Tool senkt Round-Trips, verbreitert aber Schema, Consent und Wirkung. Ein Servicekonto vereinfacht Backendzugriff, verschiebt jedoch die vollständige Autorisierungsgrenze in den Wrapper. Ein langer Timeout reduziert sichtbare Abbrüche, löst aber keine unbekannte Fachwirkung. Gute Architektur benennt Nutzen und Preis und wählt die Variante, deren verbleibendes Risiko beobachtbar und begrenzt ist.

### Zwei Grundsätze, die alle Aufgaben tragen

- **Kontrolle gehört dorthin, wo sie durchsetzbar ist.** Beschreibungen, Annotationen und Modellverhalten erklären; durchsetzen tun Rechte, Schemata und Freigaben.
- **Reihenfolge ist Teil der Sicherheit.** Eine Maßnahme, die zu spät greift, ist im Zwischenzustand keine Maßnahme.

Wirkung benennen → **Grenze an einer durchsetzbaren Stelle ziehen** → Vertrag darauf zuschneiden → Rollout begrenzen und beobachtbar machen

Durchsetzbar bedeutet deterministisch außerhalb des Modells. Betrags- und Empfängergrenzen liegen im Server oder Backend. Tenant und Objektzugriff folgen verifizierter Identität. Host-Policy entscheidet, welche Server und Tools im Arbeitsraum erscheinen. Consent zeigt konkrete Wirkung. Schema validiert Form, nicht fachliche Berechtigung. Annotations und Beschreibungen liefern Hinweise, während Filter und zweite Modelle nur probabilistische Zusatzschichten sind. Ordne jede vorgeschlagene Maßnahme dieser Stärke zu, bevor du sie als Sicherheitskontrolle zählst.

Reihenfolge ist auch im Rollout entscheidend. Identität und Datenbegrenzung stehen vor dem ersten Pilotdatensatz. Contract- und Negativtests stehen vor Capability-Aktivierung. Telemetrie steht vor der Exposition wirkender Tools, damit Fehler begrenzt rekonstruiert werden können. Der Rückweg wird vor der breiten Freigabe geprobt. Eine Kontrolle, die erst nach dem ersten Schaden hinzugefügt werden soll, ist ein bewusst akzeptiertes Risiko und braucht Owner, Frist und Kompensation.

Acht Aufgaben verbinden den Track: Scope und Capability-Schnitt, moderne Protokollära, Platzierung durchsetzbarer Kontrollen, Identität und Datenfluss, sichere Rollout-Reihenfolge, Resilienz bei unbekannter Wirkung, Trace-Diagnose eines übergriffigen Parameters und ein Design-Trade-off gegen indirekte Prompt-Injection. Die Formate wechseln zwischen Entscheidung, Boundary-Sort, Sequence und Trace, weil Senior Engineering sowohl klassifizieren als auch Reihenfolgen und Ursachen rekonstruieren muss.

Eine gute Antwort nennt nicht nur eine Technik. Sie erklärt, warum die Technik an dieser Grenze wirkt, welchen Angriff oder Fehler sie nicht löst, welche neue Komplexität entsteht und wie der Betrieb ihre Wirksamkeit belegt. Achte besonders auf bequem klingende Distraktoren: mehr Prompt, längerer Timeout, globaler Cache, pauschaler Consent, automatisches Aktivieren entdeckter Tools oder Logging vollständiger Payloads. Sie lösen meist ein lokales Symptom und verschieben den Schaden in eine weniger sichtbare Schicht.

### Zielbild: enge Fähigkeiten und autoritative Parameter

Das Zielbild trennt adressierbaren Aktenkontext von modellgesteuerten Operationen. Eine Resource kann einen bereits autorisierten, minimierten Aktenausschnitt darstellen. Tools starten fachlich atomare Suchen, Gutachteraufträge oder Zahlungen. Der Server veröffentlicht präzise Input- und Output-Schemas und behandelt Beschreibungen als Vertragserklärung, nicht als Policy. Technische CRUD-Schritte des Altsystems bleiben hinter dem Wrapper, damit kein Gespräch eine halbe Transaktion oder Sperre besitzen muss.

Wirkungsbestimmende Parameter stammen aus autoritativen Quellen. Die Bankverbindung einer Zahlung wird aus dem geprüften Fachdatensatz gewählt, nicht aus einer Kundenmail oder freiem Modelltext. Eine Änderung der Bankverbindung ist ein eigener, stärker geprüfter Vorgang. Der Betrag bleibt zusätzlich serverseitig begrenzt, Zuständigkeit wird pro Objekt geprüft, und der Host zeigt Empfänger, Betrag und Zweck in Fachsprache. Mehrere unabhängige Grenzen reduzieren verschiedene Fehler, statt dieselbe schwache Annahme zu wiederholen.

> **Entwurfsregel:** Ein Parameter mit großer Wirkung braucht eine autoritative Herkunft, einen engen Wertebereich und eine sichtbare Entscheidung am richtigen Ort.

### Stateless Protokoll und expliziter Fachzustand

Die Revision `2026-07-28` trägt Protokollversion und Client-Capabilities in jedem Request. Der Server speichert weder den letzten Tenant noch ein ausgehandeltes Capability-Set an Verbindung oder Worker. Fachzustand über mehrere Requests erhält einen opaken Handle, Ablaufzeit und erneute Autorisierung. Das erlaubt freies Routing über Replikate und verhindert, dass Verbindungspooling Nutzerkontext vermischt. `server/discover` beschreibt den Server; der Host wendet anschließend seine lokale Policy an.

Fehlen Angaben, antwortet der Server bei unterstütztem Workflow mit `resultType: input_required`. Der Client erfüllt Elicitation oder andere Input Requests und wiederholt die ursprüngliche Methode mit neuer JSON-RPC-ID, `inputResponses` und gebundenem `requestState`. Rundenzahl, Deadline und Idempotenz werden begrenzt. Langlebige Notifications laufen über `subscriptions/listen`; nach Streamverlust wird neu synchronisiert. Cancellation beendet weitere Nachrichten für die Request-ID, garantiert aber keinen Rollback bereits angestoßener Fachwirkung.

```text
request = version + clientCapabilities + principal + arguments
state   = explicitHandle + owner + expiry
resume  = newRequestId + inputResponses + boundRequestState
```

> **Invariante:** Transport und Verbindung dürfen niemals stiller Besitzer von Nutzer-, Protokoll- oder Fachzustand sein.

### Autorisierung und Datenfluss bleiben gekoppelt

Der Remote-Server folgt einer kontrollierten OAuth-Kette. Der Client validiert Protected Resource Metadata gegen den angefragten Endpoint, entdeckt den passenden Authorization Server und nutzt vorregistrierte Daten oder unterstützte Client ID Metadata Documents. Redirect-URI, State und PKCE schützen den Code Flow. Der `resource`-Parameter bindet das Token an den MCP-Server; dieser prüft Aussteller, Ablauf, Audience, Scopes und anschließend Zuständigkeit, Tenant, Objekt und Aktion. Ein korrekt signiertes Token mit falscher Audience bleibt ungültig.

Zum Backend handelt der Wrapper möglichst delegiert im Namen des Nutzers. Kennt das Altsystem nur ein Servicekonto, erzwingt der Wrapper die Bereichsgrenze selbst und wird zur sicherheitskritischen Komponente. Tooloutputs enthalten nur zwecknotwendige Felder. Caches binden Einträge an autorisierte Sicht und aktuelle Policy. Modellkontext, Konversationshistorie, Logs, Traces und Backups gehören zum Datenflussinventar; Zugangsdaten und vollständige Akten bleiben aus Standardtelemetrie heraus.

> **Prüffrage:** Kann derselbe gültige Request mit einer fremden Objekt-ID, einem alten Cursor oder Cachetreffer die aktuelle Zuständigkeitsprüfung umgehen?

### Agentenrisiko wird durch Komposition bestimmt

Die Kundenkorrespondenz ist untrusted, weil externe Absender ihren Text beeinflussen. Der Agent liest zugleich vertrauliche Akten. Kommt eine freie ausgehende Wirkung hinzu, entsteht der vollständige Abflusspfad aus fremdem Einfluss, geheimen Daten und beliebigem Empfänger. Prompt-Injection-Filter, Kennzeichnung und ein zweites Modell können die Erfolgsrate senken, sind aber probabilistisch. Das System muss eine erfolgreiche Umgehung mit begrenztem Schaden überleben.

Der Bearbeitungsmodus besitzt deshalb Aktenzugriff ohne freien Egress. Ein Gutachterauftrag nutzt ein enges Tool, dessen Empfänger aus einer geprüften Liste stammt; neue Empfänger benötigen einen eigenen Onboardingprozess. Zahlungen nutzen die hinterlegte Bankverbindung und ein Fachlimit. Consent erscheint selten und zeigt reale Wirkung. Der Host bewertet Capability-Kombinationen über alle Server, nicht jede Integration einzeln. So kann ein harmloser Dokumentenserver nicht unbemerkt ein mächtiges Sendetool eines anderen Servers steuern.

> **Ehrliche Grenze:** Detektion ist ein Sensor; Empfänger-, Daten-, Mengen- und Wirkungsgrenzen tragen die Sicherheit.

### Performance und Resilienz erhalten Fachkorrektheit

Die Journey besitzt ein End-to-End-SLO. Modellrunden, Toolkette, Queue und Backend teilen dasselbe Deadline-Budget. Kontext wird auf relevante Aktenfelder projiziert und paginiert; Concurrency ist fair pro Nutzer und teurer Capability begrenzt. Backpressure weist Überlast früh und handlungsleitend ab, statt eine wachsende Queue in Timeouts laufen zu lassen. Caching darf die Autorisierungsgrenze nie zugunsten einer höheren Trefferquote aufheben.

Wirkende Tools akzeptieren einen Idempotency-Key. Verliert der Host eine Zahlungsantwort, lautet der Zustand „unbekannt“; eine Statusprüfung klärt denselben Vorgang, bevor erneut gehandelt wird. Cancellation stoppt weitere Arbeit soweit möglich, während bereits angenommene Außeneffekte separat beobachtet werden. Ein ausgefallener Gutachterserver verschwindet vorübergehend aus der aktiven Toolmenge; begrenzte Probes ermöglichen Rückkehr. Teilausfall bleibt lokal und zieht die Aktenbearbeitung nicht vollständig mit.

> **SLO-Regel:** Schnell ist nur ein fachlich verwertbares, einmaliges und autorisiertes Ergebnis — kein früher Fehler oder Phantom-Erfolg.

### Observability erzählt dieselbe Geschichte wie die Fachwirkung

Eine Korrelation verbindet Hostinteraktion, Modellrunde, Server, Tool, Protokollprofil, Policyversion, Queue, Backend und Fachvorgang. Metriken messen End-to-End-Latenz, Vertragsfehler, MRTR-Runden, deduplizierte Retries, Sättigung und Kosten pro erfolgreichem Fall. Traces erklären einzelne Pfade; Logs halten diskrete Entscheidungen fest. Request-IDs, pseudonyme Tenantreferenzen und Ergebnisstatus genügen meist. Tokens, Prompts und Akteninhalte werden vor Export redigiert.

Protokollstatus und Fachstatus bleiben getrennt. Ein Request kann nach Timeout ohne Response enden, während die Zahlung später als ausgeführt erkannt wird. Der Trace darf beides zeigen, ohne Widerspruch zu erfinden. Nutzerstatus erklärt nächsten Schritt; Betriebstelemetrie aggregiert Ursachen. Alerts beruhen auf SLO- und Error-Budget-Verbrauch, nicht auf beliebigem Serverlogging. Ein Ausfall des Telemetrie-Exporters blockiert nicht den Datenpfad, wird aber selbst sichtbar.

> **Incident-Frage:** Welche bestätigte Wirkung trat ein, unter welchem Vertrag und welcher Policy — nicht nur: welcher HTTP-Status wurde zuletzt geloggt?

### Tests und Rollout liefern die Freigabebeweise

Contract-Tests prüfen Request-Metadaten, `server/discover`, vollständige paginierte Listen, Schemas, Fehlersemantik, MRTR und Cancellation. Deterministische Fixtures erzeugen abgelaufene Cursor, falsche Outputs, fehlende Capabilities und Streamabbrüche. Negative Autorisierungstests verwenden zwei Tenants und fremde Objekt-IDs. Lasttests prüfen faire Limits, Queueabbau und Retry-Verstärkung. Jede Produktionsinvariante besitzt Test, Metrik und Runbookreaktion.

Der Rollout beginnt mit gepinntem Artefakt und geprüfter Konfiguration. Tool-, Schema-, Scope- und Permission-Diff bilden ein Gate; Discovery aktiviert nichts automatisch. Nach Staging folgt ein kleiner Canary mit kontrollierten Identitäten und begrenzter Wirkung. Feature Flags können ein neues Tool getrennt vom Serverrelease aktivieren. Bei Verstoß blendet Host-Policy die Capability aus oder rollt auf den bekannten Stand zurück. Der Rückweg wurde vorher mit laufenden Jobs, Caches und Datenformaten geprobt.

> **Release-Regel:** Gesundheit beweist Erreichbarkeit; nur Vertrags-, Policy- und Wirkungsnachweise erlauben breite Aktivierung.

### Das Architecture Decision Record macht Urteil prüfbar

Das Ergebnis des Capstone ist kein loses Diagramm, sondern ein Architecture Decision Record. Es beschreibt Kontext und Annahmen, verworfene Alternativen, gewählte Capability-Grenzen, Identitäts- und Datenfluss, Threat Model, SLOs, Tests, Rollout, Incidentpfad und offene Risiken. Jede wesentliche Aussage verweist auf einen prüfbaren Vertrag oder eine Messung. „Das Modell soll“ gilt nicht als Durchsetzung; „der Server validiert“ nennt zusätzlich Policyquelle und Negativtest.

|  |  |
| --- | --- |
| Entscheidung | Gewählte Grenze und fachlicher Grund |
| Alternativen | Warum einfachere oder mächtigere Variante nicht passt |
| Konsequenzen | Betriebsaufwand, Einschränkung und Restgefahr |
| Evidenz | Schema, Test, Metrik, Review und Pilotbefund |
| Lifecycle | Owner, Reviewdatum, Update-, Widerruf- und Rollbackpfad |

Offene Risiken werden nicht mit Allgemeinplätzen versteckt. Beispiel: Indirekte Injection bleibt möglich, ihr Wirkungspfad ist jedoch auf autorisierte Empfänger und Beträge begrenzt; ein Red-Team-Test und Egressmetrik überwachen die Annahme. Das ADR nennt den Preis: weniger freie Automatisierung, zusätzliche Backendpolicy und gelegentliche Nutzerfreigabe. Diese Transparenz ermöglicht später eine bewusste Änderung, wenn Use Case, Protokollrevision oder Risikotoleranz wechseln.

> **Senior-Signal:** Eine starke Entscheidung macht Restunsicherheit, Kosten und Rückweg genauso sichtbar wie den gewünschten Nutzen.

### Definition of Done für den Versicherungsfall

- **Verträge:** acht enge Capabilities, aktuelle Quellen und schema-geprüfte Inputs und Outputs.
- **Identität:** Audience, Scope, Tenant, Zuständigkeit und autoritative Wirkungsparameter durchgesetzt.
- **Daten:** minimierter Kontext, sichtbare Herkunft, principalgebundene Caches und redigierte Telemetrie.
- **Risiko:** untrusted Korrespondenz von freiem Egress getrennt; Consent zeigt konkrete Wirkung.
- **Betrieb:** SLO, Backpressure, Idempotenz, Statusklärung und isolierter Teilausfall.
- **Release:** Fixture-, Contract-, Negativ- und Lasttests, Canary, Drift-Gate und geprobter Rollback.

Führe vor Freigabe einen kombinierten Ausfalltest aus: Eine manipulierte Mail nennt eine neue Bankverbindung, das Modell schlägt eine Zahlung vor, der Response geht verloren, die Queue ist angespannt und das neue Release bietet zusätzlich `change_bank_account`. Das Zielsystem muss den fremden Empfänger abweisen, der Host darf unbekannte Wirkung nicht blind wiederholen, das neue Tool bleibt ohne Policyfreigabe verborgen, und Telemetrie rekonstruiert die Entscheidungen ohne Payloadleak. Besteht dieser Pfad, greifen die Kontrollen gemeinsam statt nur in isolierten Folien.

Danach überprüft ein unabhängiger Reviewer das ADR gegen die acht Missionen. Er sucht eine fehlende Autorisierung, einen impliziten Zustand, einen ungebundenen Cache, eine probabilistische Einzelbarriere, ein ungemessenes SLO und einen ungeprobten Rückweg. Befunde ändern Vertrag oder Evidenz, nicht nur die Formulierung. Erst wenn alle harten Invarianten belegt und Restgefahren verantwortet sind, ist der Track fachlich abgeschlossen.

Der laufende Betrieb besitzt klare Trigger für Neubewertung: neue Protokollrevision, anderer Modellprovider, geändertes Backend, zusätzlicher Tenant, neue Datenklasse, neues Netzwerkziel, Capability- oder Scope-Diff und wesentliche SLO-Abweichung. Jeder Trigger öffnet gezielt die betroffenen ADR-Abschnitte und Testgates. Monatliche Reviews ersetzen keine ereignisgetriebene Prüfung, helfen aber verwaiste Owner, alte Ausnahmen und überfällige Pins zu finden. Kennzahlen zeigen nicht nur Verfügbarkeit, sondern auch Policyablehnungen, Consentfrequenz, unbekannte Fachausgänge, deduplizierte Wiederholungen, Cross-Tenant-Negativtests und Zeit bis zur Capability-Sperre. Der Versicherer kann damit belegen, dass Grenzen nicht nur beim Launch existierten, sondern im Alltag weiterwirken. Wenn eine Kontrolle dauerhaft umgangen oder ein Risiko häufiger wird, wird der Capability-Schnitt neu entworfen statt nur der Warntext verschärft. Das ist der Kern nachhaltiger MCP-Verantwortung: Veränderung wird erwartet, beobachtet und in einen kontrollierten Entscheidungsprozess zurückgeführt.

> **Abschluss:** MCP Engineering ist die Kunst, offene Komposition mit expliziten, durchsetzbaren und betreibbaren Grenzen zu verbinden. Das fertige System kann deshalb jede zentrale Wirkung jederzeit vollständig, eindeutig und nachvollziehbar auf einen autorisierten Principal, einen geprüften Vertrag, eine aktuelle Policy und einen beobachtbaren Fachzustand zurückführen. Es kennt seine verbleibende Unsicherheit, begrenzt deren möglichen Schaden und besitzt einen getesteten Weg zur wirksamen Eindämmung und sicheren, verantworteten Weiterentwicklung.

## Quellen

- modelcontextprotocol.io/specification/2026-07-28/architecture — https://modelcontextprotocol.io/specification/2026-07-28/architecture
- modelcontextprotocol.io/specification/2026-07-28/basic/index — https://modelcontextprotocol.io/specification/2026-07-28/basic/index
- modelcontextprotocol.io/specification/2026-07-28/basic/authorization — https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization
- modelcontextprotocol.io/specification/2026-07-…rns/multi-round-trip — https://modelcontextprotocol.io/specification/2026-07-28/basic/message-patterns/multi-round-trip
- modelcontextprotocol.io/specification/2026-07-28/server/discover — https://modelcontextprotocol.io/specification/2026-07-28/server/discover
- modelcontextprotocol.io/specification/2026-07-28/server/tools — https://modelcontextprotocol.io/specification/2026-07-28/server/tools
- modelcontextprotocol.io/specification/2026-07-28/server/resources — https://modelcontextprotocol.io/specification/2026-07-28/server/resources
- modelcontextprotocol.io/specification/2026-07-…er/utilities/caching — https://modelcontextprotocol.io/specification/2026-07-28/server/utilities/caching
- modelcontextprotocol.io/specification/2026-07-…lities/subscriptions — https://modelcontextprotocol.io/specification/2026-07-28/server/utilities/subscriptions
- rfc-editor.org/rfc/rfc8707 — https://www.rfc-editor.org/rfc/rfc8707
- modelcontextprotocol.io/specification/2026-07-…ilities/cancellation — https://modelcontextprotocol.io/specification/2026-07-28/basic/utilities/cancellation
- owasp.org/www-project-top-10-for-large-language-model-applications — https://owasp.org/www-project-top-10-for-large-language-model-applications/