Claude Code MCP Tasks: Hintergrundjobs und Elicitation

Für Claude Code MCP Tasks brauchst du einen MCP-Server mit Tasks-Unterstützung. Rufe dessen Tool in der Hauptkonversation der Terminal-CLI ab v2.1.304 auf: Der Server nimmt den Auftrag an, Claude arbeitet weiter und erhält später das Ergebnis. Prüfe vor Änderungen am Server die Voraussetzungen, denn ein gewöhnlicher Tool-Aufruf, der nach zwei Minuten in den Hintergrund wechselt, verwendet einen anderen Mechanismus.

Stand 2026-10-24 beschreibt die Claude-Code-Dokumentation MCP Tasks als öffentliche Beta. Dieser Leitfaden behandelt das aktuelle Protokoll 2026-07-28 und die Bedingungen, unter denen dein Aufruf als Task ausgeführt werden kann.

Was Tasks und Elicitation leisten

Nutze Tasks für längere Arbeiten, die der Server selbstständig annehmen und verfolgen kann, etwa Builds, Testläufe, Exporte oder Recherchen. Elicitation kommt zum Einsatz, wenn der Server vor dem nächsten Schritt eine Entscheidung oder fehlende Angaben von dir benötigt.

Drei Abläufe können auf den ersten Blick ähnlich aussehen:

Mechanismus	Was passiert	Was der Server implementieren muss
Gewöhnlicher MCP-Aufruf	Claude wartet auf das Ergebnis des Tools.	Eine normale Tool-Implementierung.
Automatischer Wechsel in den Hintergrund	Ein Aufruf aus der Hauptkonversation, der nach zwei Minuten noch läuft, wechselt in den Hintergrund. Das Ergebnis trifft später ein; der Hintergrundaufruf übersteht das Beenden der Sitzung jedoch nicht.	Tasks-Unterstützung ist nicht erforderlich.
MCP Task	Der Server gibt beim Annehmen des Auftrags einen Task-Handle zurück, also einen Verweis auf den Auftrag. Claude Code verfolgt diesen Handle und ruft das Ergebnis ab. Aufträge auf entfernten Servern können nach dem Beenden der CLI weiterlaufen.	Die Tasks-Erweiterung und eine persistente Aufgabenverwaltung.

Elicitation ist eine eigenständige Funktion. Ein Reporting-Tool kann zunächst nach der abzufragenden Umgebung fragen und anschließend den Export als Task starten. Auch ein schnell ausgeführtes Tool kann dieselbe Rückfrage stellen, ohne einen Task anzulegen.

Elicitation gab es bereits vor dieser Einführung: Mit Claude Code v2.1.76 kamen Elicitation-Dialoge und die Hooks Elicitation und ElicitationResult hinzu. Die neuere Funktion sind hier die vom Server verwalteten Tasks.

Prüfe, ob dein Aufruf zu einem MCP Task werden kann

Alle Bedingungen der offiziellen Checkliste müssen erfüllt sein. Eine neuere CLI-Version erfüllt lediglich die erste Zeile.

Prüfung	Erforderliche Bedingung
Claude-Code-Version	`v2.1.304` oder neuer.
Serverimplementierung	Der Server unterstützt die Tasks-Erweiterung. Eine bestehende MCP-Verbindung allein belegt diese Unterstützung nicht.
Transport und Protokoll	Ein HTTP-, stdio- oder claude.ai-Connector-Server ist mit Protokollrevision `2026-07-28` verbunden.
Einstellungen für das alte Protokoll	Weder `MCP_SDK_GENERATION=v1` noch `MCP_PROTOCOL_NEGOTIATION=legacy` darf die Verbindung auf das ältere Protokoll festlegen.
Funktionsverfügbarkeit	Die Sitzung ruft Feature-Flags ab, und Anthropic hat Tasks für diesen Sitzungstyp aktiviert.
Unterstützte Umgebung	Terminal-CLI, Agent SDK oder GitHub Actions. Die VS-Code-Erweiterung und die Desktop-App unterstützen MCP Tasks derzeit nicht.
Aufrufer	Der Aufruf stammt aus der Hauptkonversation. Aufrufe von Subagenten werden nicht zu MCP Tasks.
Eingabemodus	Eine interaktive Sitzung oder eine Agent-SDK- beziehungsweise Streaming-Eingabesitzung, die die unten beschriebenen Bedingungen erfüllt.

Für den nichtinteraktiven Betrieb benötigt eine Agent-SDK-Sitzung oder ein claude -p-Lauf mit --input-format stream-json zusätzlich:

CLAUDE_AUTO_BACKGROUND_TASKS=1
CLAUDE_CODE_DISABLE_MCP_TASK_BACKGROUND darf nicht auf 1 gesetzt sein.
CLAUDE_CODE_MCP_AUTO_BACKGROUND_MS darf nicht auf 0 gesetzt sein.

Halte den Eingabestrom offen: Sobald er geschlossen wird, wartet der Lauf nicht mehr auf MCP Tasks. Ein einmaliger Aufruf mit claude -p "..." erhält keine Tasks. Dass GitHub Actions unterstützt wird, hebt diese Anforderungen an den Eingabemodus nicht auf.

Die Referenz der Umgebungsvariablen nennt mehrere Einstellungen, die das Abrufen der Feature-Flags verhindern:

DISABLE_GROWTHBOOK=1 oder true
DO_NOT_TRACK=1
Jeder nichtleere Wert für DISABLE_TELEMETRY
Jeder nichtleere Wert für CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC

Bei den letzten beiden Variablen deaktivieren auch 0 oder false das jeweilige Verhalten. Gewöhnliche Sitzungen mit Drittanbietern, darunter Amazon Bedrock, überspringen den Abruf der Flags ebenfalls. Die Referenz nennt eine Ausnahme für Einbettungen von Claude Code, die von der Host-Anwendung verwaltet werden.

Prüfe die Umgebung, aus der du Claude Code startest, und die tatsächlich wirksamen Einstellungen. Übliche Konfigurationsdateien sind ~/.claude/settings.json, .claude/settings.json und .claude/settings.local.json; auch zentral verwaltete Einstellungen können relevant sein. Die Einstellungsreferenz erklärt die jeweiligen Geltungsbereiche.

Das Entfernen einer Einstellung für das alte Protokoll rüstet einen Server ohne Unterstützung für das neue Protokoll nicht nach. Ebenso belegt API-Kompatibilität über ein Gateway nicht, dass Feature-Flags verfügbar sind. Muss deine Bereitstellung eine blockierende Einstellung beibehalten, verwende gewöhnliche Tool-Aufrufe.

In interaktiven Sitzungen sorgt CLAUDE_CODE_MCP_AUTO_BACKGROUND_MS=0 dafür, dass Claude wartet. CLAUDE_CODE_DISABLE_MCP_TASK_BACKGROUND=1 lässt Claude ebenfalls auf Tasks warten, wobei die gewöhnliche automatische Hintergrundausführung einen langen Aufruf später trotzdem in den Hintergrund verschieben kann. CLAUDE_CODE_DISABLE_BACKGROUND_TASKS=1 allein erzwingt nicht, dass MCP Tasks im Vordergrund bleiben.

Starte einen Auftrag und prüfe das Ergebnis

Beginne mit einem authentifizierten Server, dessen Dokumentation oder Implementierung Tasks-Unterstützung belegt, und teste einen Auftrag ohne destruktive Wirkung. Prüfe in Bash zunächst die Installation und die konfigurierten Server, bevor du die interaktive CLI öffnest:

claude --version
claude mcp list
claude

Liegt eine selbstaktualisierende Installation unter der Mindestversion, führe claude update aus und prüfe die Version erneut. Diese Befehle sind in der CLI-Referenz dokumentiert.

Verwende innerhalb von Claude Code /mcp, um die Verbindung zum Server zu prüfen und eine gegebenenfalls erforderliche Authentifizierung abzuschließen. Für ein verbundenes Tool zur Testausführung eignet sich beispielsweise diese Anfrage:

Führe die Testsuite dieses Repositorys über das zugehörige MCP-Tool aus der Hauptkonversation aus. Erkläre währenddessen anhand der README, wie die Tests aufgebaut sind. Melde nach Abschluss das Ergebnis und alle fehlgeschlagenen Tests.

Prüfe das Verhalten auf zwei Ebenen:

In Claude Code: Achte auf die Anzahl der MCP Tasks und sieh unter /tasks nach. Ein Eintrag allein genügt nicht als Nachweis, weil dort auch gewöhnliche Hintergrundaufrufe erscheinen.
Im Trace deines Servers: Prüfe, ob tools/call den Wert resultType: "task" zurückgegeben hat und nachfolgende tasks/get-Anfragen dieselbe taskId verwenden.

Nach Abschluss erhält Claude Code das Ergebnis; bitte Claude, es auszugeben. Wenn Claude gerade nichts anderes bearbeitet, kann es das Ergebnis automatisch aufgreifen. Bleibt der Aufruf ein gewöhnlicher Tool-Aufruf, prüfe die vom Client in der tatsächlichen Anfrage gemeldete Unterstützung und die Voraussetzungen, bevor du das Tool umschreibst.

Für Serverautoren: Handle zurückgeben und Ergebnis bereitstellen

Implementiere die aktuelle Tasks-Erweiterung, statt ein älteres experimentelles Beispiel zu übernehmen. Mit den Änderungen in MCP 2026-07-28 wurde tasks/result durch Abfragen über tasks/get ersetzt, tasks/update ergänzt und tasks/list entfernt.

Gib nur dann einen Task zurück, wenn die Anfrage es erlaubt

Prüfe die Capability, also die angegebene Unterstützung, bei jeder Anfrage unter:

params._meta["io.modelcontextprotocol/clientCapabilities"].extensions["io.modelcontextprotocol/tasks"]

Ihr Wert ist {}. Dein Server meldet die entsprechende Erweiterung unter capabilities.extensions in seiner server/discover-Antwort. Die Übersicht zur Tasks-Erweiterung dokumentiert beide Stellen.

Wenn der Client Unterstützung meldet, entscheidet der Server, ob die konkrete Operation zu einem Task werden soll. Fehlt die Capability, gib nach Möglichkeit ein gewöhnliches Ergebnis zurück. Erfordert die Operation Tasks, sieht die Erweiterung dafür den Fehler -32021 wegen fehlender Capability vor. Gib einem nicht unterstützenden Aufrufer keinen Task-Handle zurück.

Speichere den Task vor der Antwort persistent, damit seine ID bereits über tasks/get auflösbar ist. Halte ihn auch über Verbindungswechsel hinweg abrufbar und prüfe bei Folgeanfragen die Authentifizierung sowie die Zugriffsberechtigung für den Task.

Die folgende JSON-RPC-Antwort veranschaulicht die Annahme eines Builds. ID, Zeitstempel und späteres Ergebnis sind Beispieldaten und kein Ausführungsprotokoll:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "resultType": "task",
    "taskId": "6f17bfa2-4c5e-4d21-b563-2f7e83a902bc",
    "status": "working",
    "createdAt": "2026-10-24T08:00:00Z",
    "lastUpdatedAt": "2026-10-24T08:00:00Z",
    "ttlMs": 3600000,
    "pollIntervalMs": 5000
  }
}

Die Task-Felder stehen direkt im JSON-RPC-Feld result. Es gibt keine zusätzliche task-Umhüllung, und der anfängliche Handle benötigt kein content-Array.

Feld	Anforderung
`resultType`	`"task"` für die erste Task-Antwort.
`taskId`	Erforderlich, vom Server erzeugt und schwer zu erraten. Claude Code begrenzt die ID zusätzlich auf 128 druckbare ASCII-Zeichen ohne Leerzeichen.
`status`	Erforderlich: `working`, `input_required`, `completed`, `failed` oder `cancelled`.
`createdAt`, `lastUpdatedAt`	Erforderliche Zeitstempel als Zeichenfolgen im Format ISO 8601.
`ttlMs`	Erforderliche ganzzahlige Aufbewahrungsdauer in Millisekunden ab Erstellung oder `null` für unbegrenzte Aufbewahrung. Keine Schätzung der Auftragsdauer.
`pollIntervalMs`	Optionales ganzzahliges Abfrageintervall in Millisekunden; sende nicht `null`.
`statusMessage`	Optionaler Text zu Fortschritt oder Status.

Das veröffentlichte Schema der Erweiterung definiert die Struktur. Die Claude-spezifische Validierung beschreibt die Referenz für Serverautoren.

Meldet Claude Unsupported result type 'task' for tools/call, prüfe zuerst, ob die eingehende Anfrage die Erweiterung enthielt. Stelle anschließend sicher, dass keines der Felder taskId, status, createdAt, lastUpdatedAt oder ttlMs fehlt. Ein nicht unterstützter status-Wert löst denselben Fehler aus. Eine ungültige Task-ID führt dagegen zu einem Fehler wegen eines fehlerhaft aufgebauten Task-Handles.

Liefere das fertige Tool-Ergebnis über `tasks/get`

Beantworte jede Abfrage mit dem aktuellen Zustand des Tasks. Eine erfolgreiche tasks/get-Antwort verwendet resultType: "complete", selbst wenn der status des Auftrags noch working lautet: Abgeschlossen ist die Abfrage, nicht zwingend der Auftrag.

Für den oben gezeigten Build sieht eine Antwort nach Abschluss so aus:

{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "resultType": "complete",
    "taskId": "6f17bfa2-4c5e-4d21-b563-2f7e83a902bc",
    "status": "completed",
    "createdAt": "2026-10-24T08:00:00Z",
    "lastUpdatedAt": "2026-10-24T08:03:00Z",
    "ttlMs": 3600000,
    "result": {
      "resultType": "complete",
      "content": [
        {
          "type": "text",
          "text": "Build completed successfully."
        }
      ]
    }
  }
}

Das verschachtelte result enthält das gewöhnliche Tool-Ergebnis. Auch ein Fehler auf Tool-Ebene mit isError: true gehört in einen Task mit completed. failed ist für einen JSON-RPC-Ausführungsfehler vorgesehen, der in error übermittelt wird.

Implementiere außerdem tasks/cancel, behandle den Abbruch aber als kooperativen Vorgang. Die Spezifikation der Erweiterung garantiert nicht, dass ein Abbruch bereits laufende Arbeit beendet. Claude Code ruft Ergebnisse derzeit per Polling ab; verlasse dich für die Ergebnisübermittlung daher nicht auf notifications/tasks.

Nutze Elicitation für Entscheidungen, die das Tool nicht treffen kann

Frage nach einer fehlenden Umgebung, einem Ziel oder einer Freigabe, bevor du die davon abhängige Aktion ausführst. Elicitation im Formularmodus erfasst strukturierte Felder; der URL-Modus ermöglicht einen Browserablauf, etwa eine externe Anmeldung.

Stelle eine Rückfrage während eines Tasks über tasks/get mit status: "input_required" und einer inputRequests-Map bereit. Jeder Eintrag hat einen eindeutigen Schlüssel und enthält die angeforderte method, etwa elicitation/create, sowie deren params. Claude Code sendet die Antwort über tasks/update und verwendet dabei die passenden Schlüssel in inputResponses.

Schließe in der interaktiven CLI die Ansicht /tasks, falls sie die Rückfrage verdeckt. Eine Ablehnung oder das Drücken von Esc beantwortet die Elicitation; der Server entscheidet, ob sein Auftrag danach weiterläuft.

Fordert ein Task in einer nichtinteraktiven Sitzung Benutzereingaben an, bittet Claude Code den Server um Abbruch, ohne Elicitation-Hooks oder den Callback onElicitation des Agent SDK auszuführen. Übergib erforderliche Entscheidungen vor dem Start unbeaufsichtigter Arbeit oder verwende eine interaktive Sitzung. Diese Einschränkung gilt speziell für Eingaben, die über MCP Tasks angefordert werden.

Prüfe außerdem die Hooks, bevor du eine Elicitation als menschliche Freigabe wertest. Die Hook-Referenz beschreibt folgende Möglichkeiten:

Elicitation kann automatisch antworten und den Dialog unterdrücken.
ElicitationResult kann die Antwort des Benutzers ändern und bei fehlerhafter Implementierung sogar eine Ablehnung durch Zustimmung ersetzen.
ElicitationResult wird nicht ausgeführt, wenn ein Elicitation-Hook bereits geantwortet hat.

Prüfe alle wirksamen Hooks aus Benutzer-, Projekt-, lokaler, zentral verwalteter und Plugin-Konfiguration. Wenn du nur die Einstellungsdatei im Repository kontrollierst, kannst du den Hook übersehen, der die Antwort liefert.

Was passiert beim Stoppen, Beenden, Leeren und Fortsetzen?

Stoppe einen entfernten Task ausdrücklich, wenn du einen Abbruch anfordern möchtest; das Beenden der CLI löst keinen solchen Abbruch aus. Der dokumentierte Lebenszyklus unterscheidet zwischen der Ausführung auf dem Server und der Nachverfolgung durch Claude Code.

Aktion	Ergebnis und nächster Schritt
Task unter `/tasks` auswählen und `x` drücken oder Claude bitten, ihn zu stoppen	Claude Code beendet die Nachverfolgung und fordert den Abbruch an. Der Server kann den Auftrag trotzdem noch abschließen.
Bei der gewöhnlichen Interaktion `Esc` drücken	Ein Task im Hintergrund wird dadurch nicht gestoppt.
CLI beenden, während ein entfernter Task läuft	Der Serverauftrag läuft weiter. Setze seine ursprüngliche Sitzung fort, um ihn wieder zu verfolgen.
CLI mit einem stdio-Task beenden	Der lokale Serverprozess wird beendet. Gehe nur dann von einer Fortsetzung der Arbeit aus, wenn der Server ausdrücklich eine Ausführung unabhängig von diesem Prozess unterstützt.
`/clear` oder `/branch` verwenden oder mit `/resume` die Sitzung wechseln, während Claude Code geöffnet bleibt	Das Ergebnis kann in der aktuellen Konversation eintreffen. Nach dem Beenden musst du die Sitzung fortsetzen, in der der Task ursprünglich gestartet wurde.
Die ursprüngliche Sitzung interaktiv fortsetzen	Nach dem erneuten Verbinden des Servers beginnt die Nachverfolgung wieder, sofern der Server den Task noch kennt. Behalte den Servernamen und die Verbindungseinstellungen bei.
Eine neue Sitzung starten oder `--fork-session` verwenden	Die neue Sitzung übernimmt die Nachverfolgung des Tasks nicht.
Mit einem einmaligen `claude -p`-Aufruf fortsetzen	Dieser Lauf verfolgt den Task nicht. Verwende eine interaktive Fortsetzung oder Streaming-Eingabe, die die Voraussetzungen erfüllt.

Ist der Server getrennt, verbinde ihn vor dem Stoppen des Tasks über /mcp erneut. Andernfalls erreicht ihn keine Abbruchanfrage, und Claude Code vergisst den Task.

Wähle mit claude --resume die ursprüngliche Konversation aus. Die Aufbewahrungsregeln des Servers bleiben entscheidend: Auch eine fortsetzbare Konversation kann kein Ergebnis wiederherstellen, das der Server bereits verworfen hat.

Ein Prompt zur Prüfung deiner MCP-Konfiguration

Finde mit einer rein lesenden Prüfung die kleinste sinnvolle Änderung, bevor du Server oder Einstellungen anpasst. Dieser Prompt greift den Vorschlag von @Voxyz_ai zur MCP-Prüfung auf und ergänzt Prüfungen des aktuellen Antwortformats sowie des Verhaltens von Streaming-Sitzungen.

Goal: Audit my Claude Code MCP setup for Tasks and Elicitation.

Read the current official documentation:
https://code.claude.com/docs/en/mcp
https://code.claude.com/docs/en/env-vars
https://code.claude.com/docs/en/hooks
https://modelcontextprotocol.io/extensions/tasks/overview

Scope: Inspect connected MCP servers, their configuration, effective settings, and any MCP server implementation in this repository. Say explicitly if no server implementation is present. Keep credential values out of the report.

Check:
1. Long-running tools: identify builds, test runs, exports, or research that could benefit from Tasks. For my server code, recommend the smallest change to return a valid task handle, persist it across connections, and deliver the final result through tasks/get. For third-party servers, cite evidence for the deployed version's support; otherwise mark support unknown.
2. Eligibility: check the CLI version, transport, actual protocol revision, per-request Tasks capability, feature-flag fetching, provider, supported surface, main conversation versus subagents, and input mode. Include MCP_SDK_GENERATION, MCP_PROTOCOL_NEGOTIATION, privacy/flag-fetching variables, CLAUDE_AUTO_BACKGROUND_TASKS, CLAUDE_CODE_DISABLE_MCP_TASK_BACKGROUND, and CLAUDE_CODE_MCP_AUTO_BACKGROUND_MS. Distinguish one-shot claude -p from stream-json input.
3. Elicitation: find tools that guess missing parameters or perform irreversible actions without obtaining the necessary decision. Inspect Elicitation and ElicitationResult hooks for automatic acceptance or changes to a user's refusal, including hooks outside this repository.
4. Lifecycle: check cancellation, remote versus stdio execution, retention, and resume. Identify unattended Tasks that might request user input.

Output: For each finding, name the tool or setting, cite the evidence, describe current behavior, recommend the smallest change, and give one verification step. Mark conditions you cannot observe as unknown.

Do not edit files, change settings, or invoke operational jobs during this audit. Show recommendations first.