MCP Tasks und Elicitation in Claude Code: eine Frage, die vielleicht niemand beantwortet

Am 23. Oktober hat das Claude-Code-Team Unterstützung für MCP Tasks und Elicitations angekündigt: „Tasks let Claude give plugins long-running jobs such as deep research and report back when they’re done“, und Elicitations „let plugins ask users for input mid-task“. Beides gibt es heute in der Claude Code CLI, andere Claude-Produkte sollen folgen.

Post auf X, 23. Oktober 2026, zur Besprechung wiedergegeben.

Hinter jeder Formulierung in diesem Post steckt ein Betriebsdetail, das der Post weglässt. „Report back“ heißt: Claude Code pollt deinen Server. „Long-running“ heißt: kein Zeitlimit auf Client-Seite, aber auch kein Abbruch, wenn du Claude Code beendest. „Ask users for input mid-task“ funktioniert, solange jemand am Terminal sitzt; in einem Headless-Lauf beendet eine Frage aus einem Task den Task.

Die Antworten unter dem Post fragten genau das: Wie lange darf ein Task laufen, was passiert, wenn der Client die Verbindung verliert, wer beantwortet einen Task, der nachts eine Frage stellt. Die MCP-Doku von Claude Code beantwortet das meiste in ihren Tabellen. Für den Rest habe ich einen kleinen stdio-Server geschrieben, der jede Nachricht protokolliert, Claude Code 2.1.310 darauf angesetzt und den Verkehr mitgelesen. Ein Lauf pro Bedingung, also lies die Testergebnisse als Beobachtungen, nicht als Garantien.

Was hat Claude Code für MCP Tasks und Elicitation ausgeliefert?

MCP Tasks sind neu: Public Beta in der Claude Code CLI ab v2.1.304, erschienen am 19. Oktober. Elicitation ist es nicht. Claude Code zeigt Elicitation-Dialoge seit v2.1.76 im März und hat in v2.1.281 den URL-Modus ergänzt. Neu in diesem Release ist Elicitation innerhalb eines laufenden Tasks.

Im Protokoll kamen Tasks mit der Revision 2025-11-25 als experimentelles Kernfeature, und 2026-07-28 hat sie in die Erweiterung io.modelcontextprotocol/tasks verschoben, mit Polling über tasks/get und Antworten über tasks/update.

Laut Doku wird ein Aufruf nur dann zum Task, wenn der Server auf Revision 2026-07-28 verbunden ist, die Session Feature-Flags abruft (also nicht auf Bedrock und nicht mit abgeschalteter Telemetrie) und der Aufruf aus der Hauptkonversation kommt, nicht aus einem Subagenten. Terminal-Sessions, das Agent SDK und GitHub Actions erfüllen das; die VS-Code-Erweiterung, die Desktop-App und ein einmaliges claude -p "<prompt>" nicht. Eine stream-json- oder SDK-Session braucht CLAUDE_AUTO_BACKGROUND_TASKS=1, und ihr Input muss offen bleiben, sonst endet der Lauf, ohne auf den Task zu warten. Mein einmaliger Lauf hat den Ausschluss bestätigt: Der tools/call kam ohne die Tasks-Erweiterung an, und der Server musste direkt antworten.

Wie läuft ein MCP Task in Claude Code ab?

Per Polling: „report back“ ist also eine Schleife auf Client-Seite. Der Server beantwortet tools/call mit einem Task-Handle statt eines Ergebnisses, Claude Code schiebt den Aufruf in den Hintergrund und fragt tasks/get im Takt von pollIntervalMs des Servers ab, bis der Task endet. Die Push-Benachrichtigungen der Erweiterung nutzt Claude Code nicht.

Mein Server hat 3 Sekunden zwischen den Abfragen verlangt und sie bekommen, auf 10 ms genau, so fein löst der Logger auf. Gekürzt aus dem Log, Sekunden seit dem Start:

 3.31 IN  tools/call  build_report  capabilities include io.modelcontextprotocol/tasks
 3.31 OUT result: resultType "task", status "working", pollIntervalMs 3000
 3.32 IN  tasks/get   -> working
 6.32 IN  tasks/get   -> working
 9.32 IN  tasks/get   -> working
12.32 IN  tasks/get   -> working
15.32 IN  tasks/get   -> completed, result

Die Doku begrenzt das Intervall auf 250 ms bis 30 Sekunden, mit 2 Sekunden, wenn das Feld fehlt. Das Modell bekommt ein kurzes Tool-Ergebnis: Der Server hat einen Task gestartet, das Ergebnis kommt als Benachrichtigung. Sobald das Ergebnis eintrifft, geht es an Claude, nicht ins Transkript. Ist Claude gerade untätig, greift es das Ergebnis von selbst auf; sonst schreib einen Prompt, der danach fragt.

Wie lange darf ein MCP Task in Claude Code laufen?

So lange, wie der Server ihn am Leben hält. Laut Doku hat ein Task im Hintergrund kein Zeitlimit von Claude Code, und Claude Code verwirft ihn auch nicht, wenn sein ttlMs abläuft. Die Limits für Tool-Aufrufe gelten nur, bis der Server mit dem Task-Handle antwortet: das Wall-Clock-Limit (standardmäßig etwa 28 Stunden) und der Idle-Timeout, standardmäßig fünf Minuten für HTTP-Server und dreißig für stdio, einstellbar über CLAUDE_CODE_MCP_TOOL_IDLE_TIMEOUT.

Dieser Unterschied ging in den Antworten verloren. Eine lautete:

a task that sends no progress notification for the idle window gets killed, five minutes for connector servers, thirty for stdio.

Das ist die Regel für einen normalen Tool-Aufruf, oder für einen Task, auf den Claude mit CLAUDE_CODE_MCP_AUTO_BACKGROUND_MS=0 warten muss. Ein Task im Hintergrund hat kein Idle-Limit.

Was passiert mit einem MCP Task, wenn Claude Code beendet wird oder die Verbindung verliert?

Ein Task auf einem Remote-Server läuft weiter, und nichts bittet den Server, aufzuhören. Laut Doku geht tasks/cancel raus, wenn Claude oder du den Task stoppst, solange der Server verbunden ist, beim Beenden dagegen nicht („not sent on exit“), selbst wenn der Beenden-Dialog den Task unter den Dingen aufführt, die gestoppt werden. Und ein Abbruch ist nur eine Bitte: Die Erweiterung macht ihn kooperativ, der Server darf die Arbeit trotzdem zu Ende bringen.

Um das Ergebnis später zu holen, nimm dieselbe Session interaktiv wieder auf, mit unverändertem Servernamen und unveränderten Einstellungen. Weder eine neue Session noch --fork-session noch ein einmaliges claude -p --resume findet den alten Task. stdio ist hier eine Falle: Der Server ist ein Kindprozess von Claude Code und verschwindet beim Beenden mit, obwohl /tasks den Job mit „survives exiting this session“ beschriftet.

Wenn der Server die ID vergisst, fragt Claude Code fünf Minuten lang weiter nach und meldet dann das Ergebnis als unbekannt, und die Doku warnt, dass ein zweiter Aufruf die Arbeit wiederholen kann. Ein wiederholter Build kostet Minuten; ein wiederholter Research-Job oder eine wiederholte ausgehende Nachricht ist ein Duplikat, das du bezahlst.

Wer beantwortet nachts eine MCP-Elicitation aus einem Task?

Niemand, und die zwei unbeaufsichtigten Modi scheitern unterschiedlich. Ich habe dem Testserver ein Tool gegeben, das nach ein paar Sekunden auf input_required wechselt und in inputRequests zwei Dinge anfordert: eine Formular-Elicitation („Include unpublished drafts in the report?“) und roots/list.

Im stream-json-Lauf von claude -p kam der tasks/cancel-Request direkt nach der Abfrage, die input_required lieferte; beide tragen in meinem Log denselben Zeitstempel, 9,57 Sekunden. Laut Doku führt Claude Code hier weder deine Elicitation-Hooks noch den onElicitation-Callback des SDK aus. Der Hook, der Elicitation anderswo automatisch beantworten kann, rettet einen Headless-Task also nicht. Dem Modell wurde mitgeteilt, der Task habe „asked the user a question that this session cannot show yet“, und es meldete einen Fehlschlag.

In einer interaktiven Session in einem abgekoppelten tmux-Pane erschien das Formular und wartete. Solange es offen war, hat Claude Code nicht mehr gepollt: kein tasks/get zwischen 8,80 und 48,78 Sekunden, als ich geantwortet habe. Für den Server sieht ein Task, der auf eine abwesende Person wartet, aus wie ein Client, der verstummt ist. Auf Client-Seite meldete claude agents --json die Session als waiting mit "waitingFor": "input needed", das Signal, das ein Orchestrator an einen Menschen weiterleiten kann, wie beim Steuern von Claude Code über tmux.

Als ich das Formular bestätigt hatte, trug ein einziges tasks/update beide Antworten, das Formular und die Roots. Claude Code hat meine Formularantwort direkt an den Server geschickt. Danach nach dem Ergebnis gefragt, sagte Claude, es habe die Frage nie gesehen („never saw the question“) und nicht beantwortet („didn’t answer it“), und wusste nur deshalb, was ich bestätigt hatte, weil mein Testserver die Antworten im Ergebnis zurückgab.

Für den Formularmodus gibt es noch eine Regel, die man wiederholen sollte. Die Doku illustriert ihn mit „a username and password prompt“, aber die MCP-Spezifikation zu Elicitation sagt, Server „MUST NOT use form mode elicitation to request sensitive information such as passwords, API keys, access tokens, or payment credentials“, und müssen dafür den URL-Modus nutzen. In Claude Code reicht der URL-Modus den Link an den URL-Handler deines Systems weiter, laut Doku begrenzt auf etwa 8.000 Zeichen, eher 4.000, wenn die URL überwiegend aus Prozent-Escapes besteht.

Wie baust du MCP Tasks in einen MCP-Server für Claude Code ein?

Kündige die Erweiterung an, gib nur dann ein Task-Handle zurück, wenn ein Request danach fragt, und halte die Task-ID über jede Verbindung abrufbar. Der Server listet io.modelcontextprotocol/tasks unter extensions in seinen server/discover-Capabilities. Auf Revision 2026-07-28 trägt jeder Request die Capabilities des Clients in _meta, und ein tools/call, der zum Task werden darf, enthält dieselbe Erweiterung. Antwortet der Server auf einen Aufruf ohne die Erweiterung mit einem Task, bekommt Claude laut Doku Unsupported result type 'task' for tools/call.

Das Handle ist das JSON-RPC-Ergebnis des tools/call. Aus dem Abschnitt der Doku für Server-Autoren:

{
  "resultType": "task",
  "taskId": "build-7f3a9c2e",
  "status": "working",
  "statusMessage": "Compiling, 40 of 212 files done",
  "createdAt": "2026-10-22T14:03:07Z",
  "lastUpdatedAt": "2026-10-22T14:03:07Z",
  "ttlMs": null,
  "pollIntervalMs": 5000
}

Danach antwortet tasks/get mit "resultType": "complete", denselben Pflichtfeldern und einem result bei completed oder einem error bei failed; tasks/update nimmt Antworten entgegen und tasks/cancel Abbrüche. tasks/result, tasks/list und notifications/tasks ignoriert Claude Code. Auf einem HTTP-Server antworte mit dem Handle innerhalb des Timers pro Request, also dem größten Wert aus 60 Sekunden, dem Tool-Timeout des Servers und MCP_TIMEOUT, und erledige danach die Arbeit.

Die dauerhafte ID ist das, was Tasks von einem Server verlangen. Revision 2026-07-28 hat Protokoll-Sessions entfernt, und Server, die Zustand über Aufrufe hinweg brauchen, vergeben ihre eigenen Handles. Ein zustandsloser Server, wie der Read-only-MCP-Endpunkt, den ich mit einem API-Katalog verglichen habe, kann Tasks nicht anbieten ohne Speicher, der einen einzelnen Request überdauert.

MCP Tasks übergeben den Lebenszyklus eines langen Jobs an den Server-Autor

Leg die vier Verhaltensweisen nebeneinander. Sobald ein Aufruf im Hintergrund läuft, misst Claude Code keine Zeit mehr. Es bricht beim Beenden nicht ab. Es hört auf zu pollen, solange eine Frage offen ist. Und wenn niemand am Terminal sitzt, bittet es den Server um Abbruch, statt einen Menschen zu fragen. Vielleicht ist das so gewollt, vielleicht ist es einfach der Stand einer Public Beta. So oder so ist die Summe heute dieselbe: Der Server-Autor besitzt die Frist des Jobs, sein Aufräumen und seine Duplikate, oft in einem Tool, das in der Annahme geschrieben wurde, der Client würde zusehen.

Die Arbeit dieser Woche liegt also auf dem Server. Setz einen eigenen Timeout auf input_required, denn in meinem Test blieb der Client stumm, solange das Formular offen war, und ein Formular über Nacht bleibt die ganze Nacht offen. Mach das Tool sicher gegen doppelte Aufrufe, oder gib ihm ein Status-Tool, denn „outcome unknown“ lädt zum erneuten Versuch ein. Frag alles, was sich vorab klären lässt, als Tool-Argumente ab; ein Headless-Aufrufer beendet den Task, statt zu warten. Und halte Secrets aus Formularen heraus.

Das Bild, das mir vom Test bleibt, ist das tmux-Pane: ein offenes Formular, das niemand liest, und ein Server, der alle drei Sekunden von seinem Client gehört hatte und jetzt nichts mehr hört, ohne einen langsamen Menschen von einem abwesenden unterscheiden zu können.