MCP Tasks für lange Tool Calls

Eine Mitarbeiterin bittet den Agent, die neue Ressourcenliste zu importieren und zu prüfen. Die Liste hat einige tausend Einträge. Der Agent ruft das Import-Tool auf. Dann steht der Chat still, Minute um Minute.

Nach einigen Minuten meldet der Chat einen Fehler. Wie weit der Import gekommen ist, weiß in diesem Moment niemand. Für Tasks dieser Länge hat das Model Context Protocol (MCP), der offene Standard, über den Agents die Tools anderer Anwendungen nutzen, eine eigene Extension: MCP Tasks.

Lange Tool Calls im Gespräch mit dem Agent

Das Import-Tool aus der Szene ist eine Funktion, die eine Anwendung dem Agent anbietet. Bereitgestellt wird es von einem MCP Server. Der Agent selbst läuft in einem Client, der Anwendung, in der Ihr Team mit ihm arbeitet, zum Beispiel Claude Code oder ein Agent in Microsoft Foundry. Ruft der Agent ein Tool auf, heißt dieser Schritt Tool Call. Auf die Response des Tools wartet der Agent, bevor er weiterarbeitet.

Tool Calls sind auf eine Response in Sekunden ausgelegt. Laut der Dokumentation des MCP-Projekts setzen viele Clients und Proxies im Netzwerk Timeouts, die ein Warten über wenige Sekunden hinaus unpraktisch machen. Microsoft Foundry beendet einen MCP Tool Call mit synchroner Response laut Microsoft Learn nach 100 Sekunden. An einem solchen Timeout ist der Import der Mitarbeiterin abgebrochen.

Der gängige Workaround teilt einen langen Task auf zwei Tools auf, ein Tool zum Starten und eines für das Polling, mit dem der Agent wiederholt nach dem Status fragt. Beim Polling braucht das Modell für jede Abfrage einen eigenen Turn. Jeder Turn kostet Token, die Einheiten, nach denen Modelle abgerechnet werden.

MCP Tasks ging aus einem SEP hervor, einem Specification Enhancement Proposal für das Model Context Protocol. Darin heißt dieses Polling durch den Agent unnötig teuer und unzuverlässig, weil es vom Prompt abhängt, ob der Agent überhaupt fragt. Ein Team berichtet darin, dass sein Modell Namen von Aufträgen erfand, wenn es die laufenden Tasks nicht zuerst abgefragt hatte. Lange Tool Calls brauchen deshalb einen eigenen Process im Model Context Protocol.

MCP Tasks als Abholschein

MCP Tasks ist eine offizielle Extension des Model Context Protocol, die das MCP-Projekt selbst pflegt. Mit MCP Tasks nimmt der Server einen langen Task an und gibt dem Agent eine Task ID zurück, wie einen Abholschein in der Werkstatt. Die Arbeit läuft im Background weiter. Der Client des Agents übernimmt das Polling und holt das Ergebnis ab, sobald es fertig ist.

Der Process hat vier Schritte. Zuerst ruft der Agent das Import-Tool auf. Dann nimmt der Server den Task an und gibt die Task ID zurück. Den Import führt er im Background weiter, hält dabei den Status fest und fasst ihn in einer kurzen Status Message zusammen. Im Poll Interval, das der Server vorgibt, fragt der Client nach diesem Status und holt das Ergebnis ab, sobald der Task completed ist.

Die Task ID ist durable: Der Server speichert den Task, bevor er die Task ID zurückgibt. Reißt die Verbindung ab oder startet der Client neu, setzt er laut der Dokumentation des MCP-Projekts das Polling mit derselben Task ID fort. Der Import übersteht damit einen Netzwerkfehler.

Der Nutzen von MCP Tasks im Arbeitsalltag

Mit MCP Tasks läuft der Import der Mitarbeiterin im Background. Die Mitarbeiterin bespricht mit dem Agent derweil die nächste Aufgabe. Der Agent bleibt ansprechbar, solange der Import läuft. Die Wartezeit nutzt sie für ihre eigene Arbeit.

Der Import darf so lange dauern, wie er braucht. Claude Code setzt einem Background Task laut seiner Dokumentation kein Zeitlimit. Läuft ein MCP Tool Call nach zwei Minuten noch, verschiebt Claude Code ihn in den Background. In Microsoft Foundry erarbeitet ein Agent im Background Mode seine Response asynchron. Der MCP Tool Call läuft dann ohne offene Verbindung über den Timeout von 100 Sekunden hinaus.

Das Polling übernimmt der Client, im Poll Interval, das der Server vorgibt. Er fragt mit genau der Task ID nach, die der Server vergeben hat. Laut dem SEP läuft dieses Polling im Background, ohne den Agent zu blockieren.

Unterwegs zeigt eine kurze Status Message der Mitarbeiterin, wie weit der Import ist. Braucht ein Task eine Entscheidung, etwa bei doppelten Einträgen, kann er in den Status input_required wechseln und mit einem Input Request fragen, welcher Eintrag gilt. Claude Code zeigt einen solchen Input Request in interaktiven Sessions im Terminal als Dialog, in dem sie entscheidet. Will sie den Import beenden, schickt der Client dem Server ein Cancel. Der Server beendet die Arbeit, sobald sie sich anhalten lässt.

Ist der Import fertig, holt der Client das Ergebnis ab. Der Agent legt der Mitarbeiterin die geprüfte Liste vor. Clients, die MCP Tasks nicht unterstützen, bekommen von demselben Import-Tool die gewohnte synchrone Response. Sie stellen Ihre Tools damit eines nach dem anderen um und behalten jeden Client, den Ihr Team heute nutzt.

Tools, die ähnlich lange laufen, gibt es in vielen Abteilungen. Drei Use Cases aus Controlling, Finance und Marketing zeigen, wo solche Tasks in Ihrem Unternehmen anfallen.

Datenanalyse über große Tabellen im Controlling

Für eine Frage im Controlling, etwa nach den Kosten je Kostenstelle über mehrere Jahre, durchsucht der Data Agent von Microsoft Fabric, der Datenplattform von Microsoft, große Tabellen oder führt mehrere Queries aus. Als MCP Server beantwortet er solche Fragen als Task, weil sie laut Microsoft Learn länger dauern können, als ein Client die Verbindung offen hält. Ein Agent in Microsoft Foundry erreicht den Data Agent über das Fabric IQ Tool und arbeitet im Background Mode, bis die Response den Status completed hat. Die Controllerin stellt ihre Frage im Chat und arbeitet weiter, bis die Auswertung vorliegt.

Report Export zum Monatsabschluss in der Finance

Zum Monatsabschluss stößt die Finance über den Agent einen Report Export aus der Buchhaltung an. Die Dokumentation von Claude Code nennt den Report Export als Beispiel für einen MCP Task. Mit /tasks sieht die Buchhalterin in Claude Code die laufenden Tasks und stoppt einen davon bei Bedarf per Cancel. Stellt ein Remote MCP Server den Export bereit, also ein Server im Netzwerk des Unternehmens oder in der Cloud, läuft der Export weiter, wenn sie Claude Code am Abend beendet.

Bildserie für eine Kampagne im Marketing

Für eine Kampagne braucht das Marketing eine Serie von Bildern zu einem Motiv, in mehreren Formaten. Ein Tool für Bildserien schickt alle Prompts der Serie als einen einzigen Batch Job an ein Modell, das Bilder erzeugt. Als MCP Task läuft dieser Job im Background, meist Minuten und höchstens 24 Stunden lang. Die Marketingleiterin plant mit dem Agent derweil die Texte der Kampagne. Sobald der Task completed ist, legt der Agent ihr die Bilder vor.

MCP Tasks in unseren MCP Servern

In unserem MCP Server für Bilder und Videos laufen die Erzeugung einer Bildserie und das Rendern eines Videos als MCP Task. Der Import einer langen Ressourcenliste läuft als MCP Task in einem Projekt für einen Kunden. Alle drei passen zu den Fällen, für die das MCP-Projekt Tasks empfiehlt: Tasks, die Minuten oder Stunden dauern, und Batch Processing vieler Einträge, bei dem der Zwischenstand zählt. Der MCP Server legt den Status seiner Tasks in einer Datenbank ab und beantwortet das Polling über einen Neustart hinweg. Beim Import liest der Task seinen Status aus den Einträgen, die die Anwendung zu jedem Run anlegt. Ob ein Team solche Tasks nutzen kann, entscheidet der Client, mit dem es arbeitet.

MCP Tasks in Clients und SDKs

MCP Tasks wirkt, sobald beide Seiten die Extension unterstützen: der Client, in dem Ihr Team mit Agents arbeitet, und der MCP Server mit dem langen Tool. Wer eigene MCP Server baut, braucht dafür ein SDK, das MCP Tasks mitbringt. Die Tabelle ordnet Clients, Plattformen und SDKs nach ihrem Status.

Laut der Dokumentation von Claude Code fehlen MCP Tasks in der VS Code Extension, in der Desktop App, in einem einmaligen Run mit claude -p und in Sessions über Amazon Bedrock. Der MCP Server muss dafür die aktuelle Protocol Revision des Model Context Protocol sprechen. Agents in Microsoft Foundry brauchen ein Modell, das den Background Mode unterstützt. Welcher Client in Ihrem Team läuft, bestimmt den ersten Schritt.

Der erste Schritt mit MCP Tasks

Drei Schritte passen in diese Woche:

1. Listen Sie die Tools Ihrer MCP Server auf, jedes mit der Zeit, die es typischerweise braucht. Für Agents in Microsoft Foundry zählt jedes Tool, das länger als 100 Sekunden läuft.
2. Klären Sie, in welchem Client Ihr Team die Agents nutzt, und gleichen Sie ihn mit der Tabelle ab.
3. Beginnen Sie mit dem Tool, dessen Anwendung jeden Run speichert. Der Task liest seinen Status dann aus diesen Einträgen und braucht dafür keine eigene Datenbank.

integrations.at begleitet diesen Schritt mit dem Service Komplette Integration und mit Modul 4 der Schulung Agentic Software Engineering mit Claude Code für Teams, die eigene MCP Server bauen.

Entstehung des Artikels

Alexander Kastil hat diesen Artikel und die Umstellung von Bildserie, Video und Import auf MCP Tasks beauftragt und die Umstellung freigegeben. Agents in Claude Code haben sie umgesetzt und getestet. Die Angaben zu Clients und SDKs haben Agents aus der Dokumentation und den offenen Issues der Projekte gesammelt und an den Quellen geprüft. Für die Aktualisierung haben Agents drei Use Cases vorgeschlagen, die er freigegeben hat, und den Status der Clients und SDKs an den Quellen erneut geprüft. Der Text entstand mit AI-Unterstützung.