MCP Tasks vs. synchrone Tool Calls: lange Operationen zuverlässig ausführen

Bleiben Sie bei einem normalen tools/call, wenn die Operation in einen begrenzten Request-Timeout passt, das Ergebnis sofort zurückgegeben werden kann und ein Verbindungsabbruch keine separate Wiederherstellung erfordert. Ziehen Sie einen MCP Task in Betracht, wenn die Arbeit lange läuft, einen einzelnen Request überleben muss oder Polling, Deferred Result, Cancellation oder einen Zwischenzustand input_required benötigt. Tasks gehören zur MCP-Spezifikation 2025-11-25, sind dort aber als experimental markiert. Deshalb sollten sie hinter einem Capability Gate isoliert und nicht als universeller Baseline-Vertrag behandelt werden.

Ein Task ist keine Queue, keine Workflow Engine und keine Exactly-once-Garantie. Er standardisiert die für den Client sichtbare Hülle einer lang laufenden Operation: Der Receiver erzeugt eine Task-ID und meldet den Zustand, der Requestor prüft Status und holt das Ergebnis ab. Die Business-Operation braucht weiterhin eine eigene Operation-ID, Autorisierung, Idempotency, durable State und Reconciliation mit dem System of Record. Kann der Prozess sicher in einem kurzen Call abgeschlossen werden, fügt ein Task nur Zustände und Cleanup hinzu.

• Kurzer Read oder bounded Compute → normaler tools/call.
• Lang laufende Arbeit mit Deferred Result → Task-Kandidat.
• Zusätzliche Nutzerentscheidung nötig → Task mit input_required.
• Folgenreiche Aktion → Domain-Operation-Ledger unabhängig vom Protocol Wrapper.
• Peer hat die Capability nicht angekündigt → keine Task-Augmentation senden.

Task-Unterstützung wird während der Initialisierung ausgehandelt. Für einen Task-augmented Tool Call kündigt der Server tasks.requests.tools.call an; ohne diese Capability darf der Client das Tool nicht als Task ausführen. Danach präzisiert das einzelne Tool den Vertrag über execution.taskSupport: forbidden ist der Default, optional erlaubt beide Modi, required verlangt einen Task. Prüfen Sie beide Ebenen in jeder Session und cachen Sie das Ergebnis nicht nur anhand von Servername oder SDK-Version.

Erstellen Sie ein Capability Manifest mit Protocol-Version, Server-Implementation-Version, Session Evidence, den Task-Operationen list/get/result/cancel und dem Tool-Level-Modus. Der Router vergleicht dieses Manifest vor dem ersten Aufruf mit den Workflow-Anforderungen. Fehlt eine benötigte Funktion, muss der Fallback explizit sein: kurzer synchroner Pfad, separates Job API, Human Handoff oder kontrollierte Ablehnung. Ein required Task stillschweigend in einen langen HTTP-Request umzuwandeln erzeugt andere Timeout- und Recovery-Semantiken.

Ein MCP Task startet in working und kann über die von der Spezifikation erlaubten Übergänge zu input_required, completed, failed oder cancelled wechseln. taskId wird vom Receiver erzeugt; TTL bestimmt, wann der Datensatz gelöscht werden darf; pollInterval empfiehlt die Prüffrequenz. Das tatsächliche Ergebnis holt der Requestor über tasks/result erst nach terminaler Completion ab. Speichern Sie letzten beobachteten Status, lastUpdatedAt, Correlation ID und den nächsten erlaubten Poll, damit ein Reconnect die Beobachtung fortsetzt statt die Arbeit neu zu starten.

Führen Sie parallel eine DomainOperation mit stabilem Idempotency Key, Actor, Tenant, Object Version, intended Effect, Downstream Receipt und autoritativem Outcome. completed beim Task bedeutet, dass das Protocol Result bereitsteht; es beweist nicht, dass ein externes System Payment, Publish oder Deployment akzeptiert hat. cancelled garantiert ebenfalls keine Compensation für einen bereits eingetretenen Effect. Die UI sollte Transport-/Task-State und bestätigtes Domain Outcome getrennt darstellen; unknown outcome geht vor jedem Retry in die Reconciliation.

• Task State → was der Receiver über die Ausführung des Requests meldet.
• Domain State → was das System of Record über den Business-Effekt bestätigt.
• Cancellation → Bitte, weitere Arbeit zu stoppen, kein automatischer Rollback.
• TTL Expiry → Lifecycle des Protocol Records, kein Recht, Audit Evidence zu vergessen.

Der Client respektiert pollInterval, fügt Jitter hinzu, begrenzt die Gesamtdauer und beendet Polling nach einem terminalen Zustand. Häufigeres Polling beschleunigt den Job nicht, erhöht aber Last und Rate-Limit-Risiko. Progress Notifications können die UX verbessern, dürfen den absoluten Deadline jedoch nicht unbegrenzt zurücksetzen. Nach einem Network Loss setzt der Client die Beobachtung der bekannten taskId fort, statt den auslösenden Tool Call zu wiederholen.

Definieren Sie getrennte Budgets für create, Status Reads, Result Retrieval und Business Reconciliation. Speichern Sie nur das minimal notwendige Response Envelope: Status, Version, Timestamps, sanitisierten Message-Text und Evidence Handles. Ein Fehler bei tasks/get kann Expiry, Authorization Failure oder Server Loss bedeuten; er verwandelt ein unknown Domain Outcome nicht in failed. Für große Artifacts sollte das Result bounded Metadata und einen autorisierten Handle liefern statt eines unbeschränkten Payloads im Model Context.

Die Spezifikation verlangt, Tasks an den Authorization Context zu binden, wenn er verfügbar ist. tasks/get, list, result und cancel müssen Actor, Tenant und erlaubte Operation erneut prüfen; die Kenntnis der taskId ist allein keine Permission. Kann ein Peer den Requestor nicht identifizieren, sind kryptografisch unvorhersehbare IDs, eine kürzere TTL und eingeschränkte Discovery nötig. Ein Server ohne zuverlässiges Context Binding sollte kein Task Listing anbieten.

Schreiben Sie Tokens, sensible Elicitation-Daten oder das vollständige Downstream Result nicht in statusMessage oder Logs. URL-Mode Elicitation eignet sich für einen Out-of-band Credential- oder Payment-Flow, aber accept bedeutet nur Zustimmung zum Öffnen der URL, nicht den Abschluss der externen Aktion. Für input_required protokollieren Sie die angeforderte Feldklasse, Expiry und Redaction Rule; nach Identity-Änderung oder Scope-Entzug muss die Fortsetzung des Tasks erneut autorisiert werden.

Die Contract Suite deckt initialize, fehlende Capability, jeden taskSupport-Wert, create, get, list, result, cancel, ungültige Transition, abgelaufene TTL und Pagination ab. Fault Injection trennt den Transport vor und nach CreateTaskResult, zwischen completed und Result Retrieval, während input_required und nach einem Cancel Request. Assertions prüfen, dass der ursprüngliche Call nicht automatisch wiederholt wird, Status nur über erlaubte Übergänge wechselt und Duplicate Delivery keinen zweiten Domain Effect erzeugt.

Security Cases versuchen, den Task eines anderen Tenants zu lesen oder zu canceln, eine ID zu erraten, nach Scope-Verlust ein Result abzurufen, Related-Task-Metadata zu manipulieren und Prompt Injection in Status oder Result einzuschleusen. Load Tests messen bounded Concurrent Jobs, Polling Amplification, Cleanup und Downstream Backpressure. Model-in-the-loop Evaluation ist nur dort nötig, wo das Modell den Tool-Aufruf entscheidet oder das Result interpretiert; Protocol Conformance und Authorization bleiben deterministische Gates.

• Hard Gate → Cross-Tenant-Zugriff, ungültige Transition, Duplicate Effect oder Secret Leakage.
• Recovery Gate → Reconnect setzt den bekannten Task ohne zweiten Start fort.
• Cancellation Gate → Terminal Semantics und Domain Reconciliation werden getrennt geprüft.
• Compatibility Gate → Fallback funktioniert mit einem Peer ohne Tasks-Capability.

Starten Sie mit einem read-only oder reversiblen Workflow, bei dem ein Task messbaren operativen Nutzen bringt: Er überlebt einen Request Timeout, reduziert manuelle Recovery oder macht eine lange Operation beobachtbar. Pinnen Sie Protocol- und SDK-Versionen, Capability Manifest, erlaubte Tools, maximale TTL, Concurrency, Status Retention, Owner und Kill Switch. Shadow Mode kann die State Projection mit einem bestehenden Job API vergleichen, darf die Business-Operation aber nicht doppelt ausführen.

Promoten Sie den Canary erst, wenn Contract-, Security-, Load- und Recovery-Gates bestanden sind. Rollback blockiert neue Task-augmented Starts, lässt einen Watcher für bereits erstellte Tasks aktiv, reconciliert In-flight-Domain-Operationen und stellt den verifizierten synchronen oder Job-API-Pfad wieder her. Retest nach Änderungen an MCP-Spezifikation, Experimental-Status der Tasks, SDK, Transition Schema, Authorization Context, Transport oder Downstream Idempotency. Das ist ein lokaler Kompatibilitäts-Verdict und keine Aussage, dass Tasks für jeden MCP Server besser sind.