MCP-Apps und Tasks: Steuerung der neuen MCP-Erweiterungen erster Klasse

Dasselbe MCP-Release vom 28.07.2026 das das Protokoll zustandslos machte, wertete auch zwei Erweiterungen zu erstklassigen Funktionen auf: MCP-Apps, mit denen ein Tool eine interaktive, in einem isolierten Iframe gerenderte Benutzeroberfläche zurückgeben kann, und Tasks, die langwierige Arbeiten als zustandsbehaftete Prozesse modellieren, die der Client über tasks/get, tasks/update und tasks/cancel steuert. Diese Funktionen sind äußerst nützlich – bringen jedoch neue Governance- und Sicherheitsanforderungen mit sich. Dieser Beitrag erläutert ihre Funktionsweise, die damit verbundenen Risiken und warum das Gateway der ideale Ort für deren Steuerung ist.

Hana, eine Product Engineer, veröffentlichte ein MCP-Tool zur Erstellung von Quartalsberichten und nutzte beide neuen Erweiterungen für eine bessere Benutzererfahrung. Sie implementierte eine MCP-App – eine interaktive Vorschau, die der Nutzer in einem isolierten Bereich anpassen konnte – und modellierte den Berichtsvorgang als Task, da die Erstellung einige Minuten dauerte und der Aufruf so nicht blockiert wurde. Die Demo war ein Erfolg. Die Probleme traten erst in der darauffolgenden Woche auf. Die gerenderte Vorschau der App enthielt einen Anbieternamen, der direkt aus einem nicht vertrauenswürdigen Datensatz stammte. Ein Teamkollege wies darauf hin, dass es keine Filterung für die Inhalte gab, die in dieser Oberfläche angezeigt wurden – also genau die Inhalte, die auch das Modell auslesen würde. Zudem lief ein Task zur Berichterstellung achtzehn Minuten lang, verbrauchte unbemerkt Token und zeigte weder Fortschritt noch Kosten an, bis er schließlich abgeschlossen war.

Beides waren keine Fehler in Hanas Code. Es waren die neuen Oberflächen, die genau das taten, was die Spezifikation erlaubt, in einem System, das zwar Tool-Aufrufe steuerte, aber keine gerenderten UIs oder langwierigen Tasks. Das Release vom 28.07.2026 vereinfachte nicht nur den Transport; es schuf zwei neue Bereiche, in denen Wert – und Risiko – entstehen. Dieser Beitrag zeigt, wie man diese Funktionen nutzt, ohne Hanas Probleme zu erben.

1. Was MCP-Apps und -Tasks sind und warum sie jetzt erstklassig sind

Das Release hat die Erweiterungen zu einem echten Framework umstrukturiert: Jede Erweiterung erhält eine Reverse-DNS-Kennung, ein eigenes Repository mit Betreuern und eine Versionsnummer, die unabhängig von der Kernspezifikation verwaltet wird. Clients und Server verhandeln die Unterstützung über eine Erweiterungs-Map in ihren Capabilities – ein Server gibt an, dass er MCP-Apps oder eine bestimmte Task-Version unterstützt, der Client tut dasselbe, und bei Übereinstimmung wird die Funktion genutzt; andernfalls funktioniert die Verbindung auch ohne sie. MCP-Apps und -Tasks sind die ersten beiden erstklassigen Beispiele.

Wichtig ist, dass keines von beiden das Tool-Prinzip ersetzt. Ein Tool nimmt weiterhin JSON-Argumente entgegen und liefert JSON-Ergebnisse zurück. Eine App fügt einem Tool eine optionale gerenderte Oberfläche hinzu; ein Task ändert die Art und Weise, wie das Ergebnis bei langwierigen Prozessen übermittelt wird. Deshalb sind sie am besten als Erweiterungen zu verstehen – und deshalb muss die Governance, die Sie bereits für Tools anwenden, auf diese Funktionen ausgeweitet und nicht durch sie ersetzt werden.

2. MCP-Apps: Serverseitig gerenderte UI als neue Oberfläche

Eine MCP-App ermöglicht es einem Tool, eine interaktive UI-Ressource zurückzugeben, die der Host in einem isolierten Iframe rendert. Die Analogie aus der Spezifikationsdiskussion ist treffend: Sie erweitert ein Tool so, wie ein gehostetes Dashboard eine API erweitert. Der JSON-Vertrag des Tools bleibt unverändert; die App ist die interaktive Hülle, die der Host dem Benutzer anzeigt. Für Hanas Berichtstool ist die App das Vorschaufenster.

Die Funktion wird ausgehandelt, nicht vorausgesetzt. Ein Server deklariert die App-Erweiterung in seinen Capabilities, und ein Host, der keine Apps unterstützt, erhält einfach das JSON-Ergebnis und rendert nichts zusätzlich. Dieses "Graceful Degradation"-Prinzip ist gutes Design – bedeutet aber auch, dass die App-Oberfläche optional ist und leicht implementiert werden kann, ohne die Konsequenzen zu bedenken, was das Thema des nächsten Abschnitts ist.

3. Die Sicherheitsoberfläche von Apps: Sowohl der Benutzer als auch das Modell lesen sie

Das neue Risiko bei einer App besteht darin, dass ihr gerenderter Inhalt zwei Zielgruppen hat. Der Benutzer sieht ihn, daher ist jeder nicht vertrauenswürdige Inhalt, der im Panel gerendert wird, ein clientseitiges Sicherheitsthema – der isolierte Iframe begrenzt den Schadensradius, weshalb der Host ihn isoliert rendert. Doch "isoliert" begrenzt nur, was das Markup dem Host antun kann, nicht was das Inhalt sagen. Je nach Verhalten des Hosts können der Inhalt der App, die zugrunde liegenden Daten oder durch die Benutzeroberfläche ausgelöste Aktionen in den Modellkontext zurückfließen. Daher ist nicht vertrauenswürdiger Text, der in einer App gerendert wird, ein weiterer Weg für die indirekte Prompt-Injection, die wir in unserem Beitrag zur Prompt-Injection: Anweisungen, die in ein Feld eingeschleust werden und schließlich vor dem Modell landen.

Der pragmatische Ansatz besteht darin, App-Inhalte als nicht vertrauenswürdige Ausgabe zu behandeln, die dieselbe Überprüfung erfordert wie jeder andere modellnahe Inhalt: Scannen und bereinigen Sie alles, was gerendert wird, interpolieren Sie niemals rohe, nicht vertrauenswürdige Daten ohne Maskierung in die Oberfläche und halten Sie die Sandbox der App strikt. Das Feld „vendor-name“ bei Hana ist der klassische Fehler – nicht vertrauenswürdige Daten, die in eine gerenderte Oberfläche interpoliert werden, die sowohl vom Benutzer als auch vom Modell konsumiert wird, ohne dass dazwischen eine Schutzmaßnahme greift.

4. Tasks: Lang laufende Prozesse in einem zustandslosen Protokoll

Tasks waren im Core vom 25.11.2025 experimentell; die Version vom 28.07.2026 überführt sie in eine offizielle Erweiterung mit einem Lebenszyklus, der für die zustandslose Welt konzipiert ist. Das Modell ist anforderungsgesteuert: Ein Server kann einen „tools/call“ mit einem Task-Handle anstelle eines sofortigen Ergebnisses beantworten, und der Client steuert dann die Arbeit mit „tasks/get“, „tasks/update“ und „tasks/cancel“. (Die frühere experimentelle Oberfläche vom 25.11.2025 enthielt auch „tasks/list“ und „tasks/result“; der Release Candidate gestaltet den Lebenszyklus um „get/update/cancel“ neu und entfernt „tasks/list“, das nicht sicher begrenzt werden kann, sobald das Protokoll zustandslos ist. Betrachten Sie den genauen Methodensatz als RC-spezifisch und bestätigen Sie die Ergebniszustellung anhand der finalen Spezifikation.) Ein Task ist im Grunde eine kleine, dauerhafte Zustandsmaschine plus ein Zeiger auf ihr Ergebnis.

Die Unterstützung wird granular ausgehandelt – ein Peer sagt nicht einfach „Ich unterstütze Tasks“, sondern gibt an, welche Anfragen mit Tasks erweitert werden können. Die Capabilities-Map ist diesbezüglich explizit:

Task-Aushandlung im RC vom 28.07.2026 – illustrativ; bestätigen Sie die genaue Erweiterungs-ID und das Schema anhand der finalen Spezifikation

{
  "capabilities": {
    "extensions": {
      "io.modelcontextprotocol.tasks": {   // reverse-DNS extension identifier
        "requests": {
          "tools": { "call": {} }          // only tools/call may be task-augmented here
        }
      }
    }
  }
}

Die obige Struktur dient zur Veranschaulichung des Erweiterungs-Frameworks des RC, nicht als wortgetreues Schema. Die frühere Form „capabilities.tasks“ mit „tasks/list“ gehörte zum 25.11.2025 experimentellen Tasks-API; der RC verschiebt die Aushandlung in eine über Reverse-DNS identifizierte Erweiterungs-Map. Bestätigen Sie den finalen Bezeichner und die Felder anhand der Spezifikation vom 28. Juli, bevor Sie die Implementierung vornehmen.

Alles, was nicht unter „requests“ aufgeführt ist, bleibt synchron; ein Client darf nicht versuchen, eine Anfrage mit Tasks zu erweitern, die der Server nicht angekündigt hat. Dies ist der saubere, MCP-native Weg für Nebenläufigkeit, ohne Seitenkanäle erfinden zu müssen – und er lässt sich mit dem zustandslosen Core kombinieren, da das Task-Handle ein expliziter, vom Server erstellter Bezeichner ist, den der Client zurückgibt. Genau das ist das Muster für expliziten Zustand, das das zustandslose Modell fördert.

5. Überwachung eines Tasks: Lebenszyklus, Fortschritt und Kosten

Hanas achtzehnminütiger „blinder Fleck“ ist das operative Herzstück von Tasks. Ein lang laufender Task, der erst nach Abschluss ein Ergebnis liefert, ist eine Blackbox: Man kann keinen Fortschritt anzeigen, keine anfallenden Kosten einsehen und nicht zwischen einem hängenden und einem langsamen Task unterscheiden. Der Lebenszyklus bietet Ihnen die notwendigen Hooks – der Client fragt den Status ab und kann Fortschritte sowie Zwischenaktualisierungen anzeigen –, aber jemand muss diese Übergänge aufzeichnen, die während der Laufzeit verbrauchten Token summieren und diese Informationen bereitstellen.

Einen Task bis zum Abschluss steuern mit Sichtbarkeit bei jedem Schritt (illustrative Client-Schleife)

resp = call_tool("generate_report", args, task_augmented=True)
task_id = resp.task_id                       # server-minted handle

while True:
    state = tasks_get(task_id)                # poll; gateway records each transition
    emit_progress(task_id, state.status, state.progress, state.tokens_so_far)
    if state.status == "input_required":
        tasks_update(task_id, provide_input())
    elif state.status in ("completed", "failed", "cancelled"):
        break
    sleep(backoff())                          # respect the server's polling guidance

result = state.result if state.status == "completed" else None  # final result shape is RC-specific

Dies ist dieselbe Geschichte der Beobachtbarkeit wie im Rest der Serie, angewendet auf ein neues Objekt. Das Tracing eine normale Anfrage erfasst, sollte einen Task als Span behandeln, der über seinen gesamten Lebenszyklus hinweg geöffnet bleibt, wobei ihm Token- und Kostenabrechnungen direkt zugeordnet werden. TrueFoundrys MCP Gateway verfolgt bereits jeden MCP-Serveraufruf und ordnet die Nutzung nach Benutzer, Tool und Team zu; ein Task ist genau diese Telemetrie, die über die Zeit hinweg erweitert statt nur in einem einzigen Moment erfasst wird – und genau das ist das fehlende Puzzleteil in Hanas Berichtstool.

6. Governance: Wer darf Apps und Tasks mit welchem Budget starten?

Das Protokoll legt fest, wie Apps und Tasks funktionieren; wer sie unter welchen Bedingungen nutzen darf, überlässt es bewusst Ihnen. Das ist eine Governance-Lücke mit konkreten Fragen. Welche Agenten oder Benutzer dürfen überhaupt einen langlebigen Task starten? Wie hoch sind das Timeout und das Token-Budget, bevor ein Task zwangsweise abgebrochen wird – damit eine achtzehnminütige Laufzeit eine bewusste Richtlinienentscheidung und kein Versehen ist? Welche Tools dürfen eine App zurückgeben und welche Inhalte dürfen darin gerendert werden?

Beispielhafte Gateway-Richtlinie für die neuen Oberflächen (das Schema ist Gateway-spezifisch)

tasks:
  allow_launch:
    roles: ["agent:report-writer", "team:finance"]   # default-deny otherwise
  limits:
    max_runtime_seconds: 300                           # force-cancel past this
    max_tokens: 200000                                 # budget ceiling per task
  observability: trace_lifecycle                       # record every state transition

apps:
  output_guardrails: [pii, injection, toxicity]        # scan rendered content
  sandbox: strict                                      # host renders in a locked-down iframe

Nichts davon ist exotisch; es ist dieselbe Mechanik für rollenbasierte Zugriffssteuerung, Budgets und Sicherheitsvorgaben, die bereits auf Modell- und Tool-Aufrufe angewendet wird, nur erweitert auf zwei neue Objekte. Der Grund für die Zentralisierung liegt darin, dass Apps und Tasks von vielen Agenten über viele Server hinweg genutzt werden. Eine Implementierung pro Server oder pro App führt dazu, dass der achtzehnminütige Task oder das ungeprüfte Panel durch das Raster fallen. Ein zentraler Richtlinienpunkt macht aus der Frage „Wer darf einen Task starten, wie lange und was darf in einer App gerendert werden?“ eine einzige Antwort statt vieler.

Sicherheitsvorgaben werden hier konkret, da das Gateway Inhalte bereits über eine dokumentierte Reihe von Hooks prüft. TrueFoundrys Gateway bietet vier davon – llm_input und llm_output für den Modellverkehr sowie mcp_pre_tool und mcp_post_tool für den Tool-Verkehr – an die eine beliebige Anzahl von Validatoren (PII-Erkennung, Suche nach Geheimnissen, Prompt-Injection- und Toxizitätsklassifikatoren, SQL-Sanitizer, Richtlinienprüfungen via Cedar oder OPA) angeschlossen werden kann. Diese laufen parallel zur gleichen Anfrage, sodass eine Eingabeprüfung gleichzeitig mit dem Modellaufruf erfolgt und diesen noch vor der Token-Abrechnung abbrechen kann, falls er blockiert wird. Die operative Disziplin, die dies in der Produktion sicher hält, ist ein gestaffelter Rollout – erst Audit (Verstöße protokollieren, Verkehr durchlassen), dann Durchsetzung (bei Fehlern blockieren, bei Anbieterfehlern offen lassen), dann strikt –, damit ein Ausfall eines Sicherheitsanbieters niemals den gesamten Pfad lahmlegt.

7. Migration: Von experimentellen Tasks zum neuen Lebenszyklus

Wenn Sie die experimentelle Tasks-API aus dem Core vom 25.11.2025 übernommen haben, ist der Wechsel zur Erweiterung eine echte Migration, keine bloße Umbenennung. Der Lebenszyklus und die Methoden sind nun um tasks/get, tasks/update und tasks/cancel herum organisiert, und die Aushandlung der Fähigkeiten ist nun explizit und granular. Die gute Nachricht: Die in dieser Version eingeführte Deprecation-Richtlinie garantiert eine Überschneidungszeit von mindestens zwölf Monaten zwischen der Veraltung und der Entfernung von Funktionen, sodass die alte Oberfläche während des Übergangs weiter funktioniert, anstatt zu einem bestimmten Datum einfach auszufallen.

Der risikoarme Weg ist der, den die zustandslose Migration bereits nahelegt: Schreiben Sie Tools, die explizite Handles erstellen und erfordern, handeln Sie die Tasks-Erweiterung aus, anstatt sie vorauszusetzen, und behandeln Sie den Release Candidate als vorläufig – er wurde am 21. Mai 2026 fixiert und wird voraussichtlich am 28. Juli finalisiert, wobei sich der Spezifikationstext im Validierungsfenster noch ändern kann. Ein Gateway, das während der Übergangsphase sowohl die experimentelle als auch die erweiterte Form beherrscht, ist hier von echtem Nutzen, genau wie es Sie beim Übergang zum zustandslosen Transport absichert.

8. Wo dies hingehört: Das Gateway als Governance-Punkt

Apps und Tasks verstärken ein Muster, auf das diese Serie immer wieder zurückkommt: Das Protokoll definiert den Mechanismus, und das Gateway liefert die Governance, die das Protokoll offen lässt. Das MCP Gateway fungiert bereits vor jedem registrierten MCP-Server als zentraler Punkt für Discovery, Authentifizierung, RBAC und Request-Tracing – genau die Oberfläche, an der App-Inhalte gefiltert und Task-Lebenszyklen beobachtet und begrenzt werden können.

Konkret bedeutet das, dass App-gerenderte Inhalte dieselben Output-Sicherheitsvorgaben durchlaufen wie jeder andere modellnahe Output, und ein Task als langlebiger Span nachverfolgt wird, dessen Token und Kosten dem startenden Agenten zugeordnet werden – unter Nutzung der Discovery, RBAC und Beobachtbarkeit, die das MCP Gateway ist bereits vorhanden, anstatt ein zweites Governance-System auf jeden Server aufzusetzen. Die Arbeitsteilung ist bekannt: Der Server implementiert die App oder Aufgabe; das Gateway steuert, wer sie nutzen darf, was sie rendern darf, wie lange sie laufen darf und was sie kostet.

9. FAQs

Sind MCP-Apps nur eine Möglichkeit, HTML zurückzugeben?

Genauer gesagt erweitert eine App ein Tool um eine interaktive UI-Ressource, die der Host in einem isolierten Iframe rendert – das Tool empfängt und sendet weiterhin JSON, und die App fungiert als optionale Hülle darüber. Für die Governance ist dies deshalb wichtig, weil die gerenderten Inhalte generiert werden, oft aus nicht vertrauenswürdigen Eingaben, und über das Host-Verhalten, Tool-Ausgaben oder UI-initiierte Aktionen in den Modellkontext zurückfließen können. Daher fallen sie unter die Output-Guardrails und sollten nicht als harmlose Präsentation betrachtet werden.

Macht das zustandslose Protokoll Aufgaben (Tasks) überflüssig?

Nein – sie lösen unterschiedliche Probleme. Ein zustandsloser Transport bedeutet, dass keine Anfrage an eine bestimmte Instanz gebunden ist; Tasks bilden Arbeitsprozesse ab, die länger als eine einzelne Anfrage-Antwort-Zyklen dauern, unabhängig davon, welche Instanz die jeweilige Abfrage bedient. Tatsächlich ist das Task-Handle genau das Muster für expliziten Zustand, das das zustandslose Modell fördert: ein vom Server erstellter Bezeichner, den der Client weiterreicht, sodass jede Instanz den Status der Aufgabe abrufen kann.

Was ist das größte neue Risiko, das man einplanen sollte?

Zwei Dinge. Erstens: Bei Apps sind gerenderte, nicht vertrauenswürdige Inhalte auf der Oberfläche als Ausgaben zu behandeln, die auf Injektionen und PII geprüft werden müssen, nicht als harmloses Markup. Zweitens: Bei Tasks sind unbegrenzte, lang laufende Prozesse zu beachten – setzen Sie Timeouts und Token-Budgets, damit ein außer Kontrolle geratener Task richtlinienbasiert abgebrochen wird, und verfolgen Sie den Lebenszyklus, damit er keine Blackbox bleibt. Beides ist Governance, die Sie um die Spezifikation herum aufbauen, nicht ein Verhalten, das die Spezifikation selbst vorgibt.

Muss ich jetzt migrieren?

Planen Sie jetzt; der Release Candidate wurde am 21. Mai 2026 eingefroren und wird voraussichtlich am 28. Juli finalisiert. Falls Sie die experimentelle Tasks-API genutzt haben, wird es Breaking Changes geben. Die zwölfmonatige Übergangsfrist bedeutet, dass an diesem Datum nichts sofort ausfällt, aber neue Projekte sollten auf den Erweiterungs-Lebenszyklus setzen und Funktionen explizit aushandeln. Betrachten Sie den RC bis zur Ratifizierung als vorläufig.

App- oder Task-Governance – Gateway oder Anwendung?

Das Gateway ist für die übergreifenden Kontrollen zuständig: Welche Agenten dürfen Apps und Tasks starten, wie hoch sind die Timeouts und Budgetobergrenzen, welche Output-Guardrails gelten für gerenderte Inhalte und wie sieht das Lebenszyklus-Tracing aus – alles einheitlich über jeden MCP-Server hinweg angewendet. Die Anwendung selbst behält die Hoheit über die Domänenlogik, also was die App anzeigt und was der Task tut, da dies Wissen erfordert, über das das Gateway nicht verfügt.

Das Release vom 28.07.2026 wird vor allem für die Umstellung auf Zustandslosigkeit in Erinnerung bleiben, aber Apps und Tasks sind der Teil, der Ihre Arbeitsweise verändert. Sie fügen eine gerenderte Oberfläche und eine für lang laufende Prozesse hinzu, wobei die Spezifikation Ihnen den Mechanismus an die Hand gibt, die Governance jedoch offen lässt. Schließen Sie diese Lücke am Gateway – prüfen Sie, was gerendert wird, begrenzen Sie, was läuft, und verfolgen Sie beides –, dann wird aus Hanas guter Demo ein produktionsreifes System.

Wenn das Gateway der Ort ist, an dem Sie diese Oberflächen steuern, ist es hilfreich, dass dieselbe Steuerungsebene auch der Ort ist, an dem die Agenten laufen, die sie nutzen. TrueFoundrys AI Gateway ist der einheitliche Einstiegspunkt für Modell-, MCP- und Tool-Traffic, und sein Agent Harness ist die Laufzeitumgebung, die die Plan-Act-Observe-Schleife eines Agenten, das Sandboxing, Freigaben und das Tracing darüber orchestriert – sodass die App-Inhalte, die ein Agent rendert, und die Tasks, die er startet, von derselben Ebene geprüft, begrenzt und nachverfolgt werden, auf der der Agent läuft, anstatt durch eine nachträglich aufgesetzte Governance-Schicht.

Referenzen

• Model Context Protocol – Der Release Candidate vom 28.07.2026 (Erweiterungen, MCP-Apps, Tasks)
• MCP 25.11.2025 – Experimentelle Tasks-API (die bisherige Oberfläche; der RC vom 28.07.2026 formt sie zu einer Erweiterung um)
• TrueFoundry – MCP-Gateway (Discovery, RBAC, Observability)
• Unsere Prompt-Injection und OpenTelemetry für LLMs Beiträge – Output-Guardrails und Tracing, angewendet auf die neuen Oberflächen.

Northwind und Hana dienen der Veranschaulichung. Die Details zu MCP-Apps und Tasks basieren auf den offiziellen Materialien zum Model Context Protocol Release Candidate vom 28.07.2026 sowie zugehörigen Berichten vom späten Mai 2026; der RC wurde am 21. Mai finalisiert und die Ratifizierung wird für den 28. Juli 2026 erwartet. Da sich der Spezifikationstext noch ändern kann, sind Protokollspezifika – wie Methodennamen, Capability-Strukturen und Lebenszyklus-Zustände – als vorläufig zu betrachten und anhand der finalen Spezifikation zu prüfen. Codebeispiele dienen der Veranschaulichung der dokumentierten Muster und sind keine Kopien einer Referenzimplementierung. Die Funktionen von TrueFoundry sind aus der öffentlichen Produktdokumentation zusammengefasst und werden sich weiterentwickeln.

‍