Transport und Resilienz: Grenzen unter Störung
Ein Timeout beweist nur, dass keine Antwort ankam. Wer daraus „nicht ausgeführt“ macht und automatisch wiederholt, verwandelt eine kurze Netzstörung in eine doppelte Rückzahlung. Resilienz beginnt mit ehrlichen Zuständen, nicht mit mehr Retries.
Fortgeschritten · ~25 Min · 11 Abschnitte Einführung · 8 Übungen (davon 1 Mission)
Modul starten →
Fortschritt wird gespeichert — du kannst das Modul später jederzeit fortsetzen.
Das kannst du danach
- ✓Transportwahl als Entscheidung über Identität, Reichweite und Betriebsverantwortung begründen
- ✓Langläufer, Streamabbrüche und Wiederholungen mit Status und Idempotenz beherrschen
- ✓Fehlerkanäle und Retry-Budgets so gestalten, dass Teilausfälle lokal bleiben
Übungen
- 1. EntscheidungWas ist die tragende Entscheidung für den Schritt in den Regelbetrieb?
- 2. EntscheidungWelche Einschätzung ist korrekt?
- 3. EntscheidungWelche Korrektur passt zur aktuellen MCP-Architektur?
- 4. EntscheidungWelche Kombination löst das Problem an der richtigen Stelle?
- 5. MissionFehler an den richtigen Adressaten senden
- 6. EntscheidungWie verhinderst du die Doppelwirkung?
- 7. EntscheidungWie beurteilst du diese Meldung?
- 8. EntscheidungWie reagiert der Host?
Quellen & Aktualität7 Primärquellen · zuletzt geprüft:
- 01modelcontextprotocol.io/specification/2026-07-28/architecture
- 02modelcontextprotocol.io/specification/2026-07-28/basic/index
- 03modelcontextprotocol.io/specification/2026-07-28/basic/versioning
- 04modelcontextprotocol.io/specification/2026-07-…ilities/cancellation
- 05modelcontextprotocol.io/specification/2026-07-28/server/discover
- 06modelcontextprotocol.io/specification/2026-07-28/server/tools
- 07jsonrpc.org/specification
Verfasst von Julian Zentgraf