MCP Apps en Tasks: Governance voor de Nieuwe First-Class MCP-extensies

Dezelfde MCP 2026-07-28 release die het protocol stateless maakte, heeft ook twee extensies gepromoveerd tot first-class status: MCP Apps, waarmee een tool een interactieve UI kan teruggeven die in een gesandboxte iframe wordt gerenderd, en Tasks, die langlopend werk modelleren als een duurzame state machine die de client aanstuurt met tasks/get, tasks/update en tasks/cancel. Ze zijn ontzettend nuttig — én ze vormen compleet nieuwe oppervlakken voor governance en beveiliging. Deze blogpost legt uit hoe beide werken, waar het nieuwe risico zit en waarom de gateway de aangewezen plek is voor de governance ervan.

Hana, een product engineer, leverde een "generate quarterly report" MCP-tool op en gebruikte beide nieuwe extensies om de ervaring te verbeteren. Ze retourneerde een MCP App — een interactieve preview die de gebruiker in een gesandboxt paneel kon aanpassen — en omdat de generatie een paar minuten duurde, modelleerde ze het als een Task zodat de call niet blokkeerde. De demo was geweldig. De problemen kwamen de week erna. De gerenderde preview van de App bevatte een leveranciersnaam die rechtstreeks uit een onvertrouwd record was gehaald, en een teamgenoot wees erop dat niets controleerde wat er in dat oppervlak werd gerenderd — dezelfde inhoud die het model weer zou uitlezen. En één rapport-Task draaide achttien minuten lang, terwijl deze stilzwijgend tokens verbruikte, zonder dat er voortgang of kosten zichtbaar waren totdat deze eindelijk iets retourneerde.

Geen van beide was een bug in Hana's code. Het waren de nieuwe oppervlakken die precies deden wat de spec toestaat, in een systeem dat wel governance had voor tool-calls, maar niet voor gerenderde UI's of langlopende taken. De release van 2026-07-28 heeft niet alleen het transport vereenvoudigd; het voegde twee plekken toe waar waarde — en risico — nu wonen. Deze post legt uit hoe je hierop kunt bouwen zonder de week van Hana te herbeleven.

1. Wat MCP Apps en Tasks zijn, en waarom ze nu First-Class zijn

De release heeft extensies geherstructureerd tot een volwaardig framework: elke extensie krijgt een reverse-DNS-identifier, een eigen repository en onderhouders, en een versie die onafhankelijk van de core-spec beweegt. Clients en servers onderhandelen over ondersteuning via een extensions-map in hun capabilities — een server maakt kenbaar dat deze MCP Apps of een specifieke versie van Tasks spreekt, de client doet hetzelfde, en als beiden akkoord gaan gebruiken ze het; zo niet, dan werkt de verbinding nog steeds zonder. MCP Apps en Tasks zijn de eerste twee first-class voorbeelden.

Cruciaal is dat geen van beide de tool-primitieve vervangt. Een tool accepteert nog steeds JSON-argumenten en retourneert JSON-resultaten. Een App voegt een optioneel gerenderd oppervlak toe bovenop een tool; een Task verandert hoe het resultaat van een tool-call wordt geleverd wanneer het werk lang duurt. Daarom kun je ze het beste zien als uitbreidingen — en waarom de governance die je al toepast op tools moet worden uitgebreid om ze te dekken, in plaats van te worden vervangen.

2. MCP Apps: Server-Rendered UI als een nieuw oppervlak

Met een MCP App kan een tool een interactieve UI-resource retourneren die de host in een gesandboxte iframe rendert. De analogie uit de spec-discussie is passend: het breidt een tool uit zoals een gehost dashboard een API uitbreidt. Het JSON-contract van de tool blijft ongewijzigd; de App is de interactieve schil die een host aan de gebruiker kan tonen. Voor Hana's rapport-tool is de App het previewpaneel.

De capability wordt onderhandeld, niet aangenomen. Een server verklaart de App-uitbreiding in zijn capabilities, en een host die geen Apps ondersteunt, krijgt gewoon het JSON-resultaat en rendert niets extra's. Die 'graceful degradation' is een goed ontwerp — maar het betekent ook dat het App-oppervlak optioneel is en gemakkelijk kan worden opgeleverd zonder na te denken over wat het introduceert, wat het onderwerp is van het volgende gedeelte.

3. Het beveiligingsoppervlak van Apps: Zowel de gebruiker als het model leest het

Het nieuwe risico in een App is dat de gerenderde inhoud twee doelgroepen heeft. De gebruiker ziet het, dus alles wat onvertrouwd in het paneel wordt gerenderd, is een contentvraagstuk aan de clientzijde — het gesandboxte iframe beperkt de impact, wat precies is waarom de host het gesandboxt rendert, maar "gesandboxt" begrenst wat de markup de host kan aandoen, niet wat de inhoud kan zeggen. Afhankelijk van het gedrag van de host kunnen de inhoud, de achterliggende gegevens of door de UI geïnitieerde acties van de App terugvoeden in de modelcontext. Onvertrouwde tekst die in een App wordt gerenderd, is dus een extra route voor de indirecte prompt injection die behandeld wordt in onze prompt-injection post: instructies die binnengesmokkeld worden in een veld dat uiteindelijk bij het model terechtkomt.

De praktische aanpak is om App-inhoud te behandelen als onvertrouwde output die dezelfde controle nodig heeft als elke andere inhoud die aan het model grenst: scank en opschoon wat er wordt gerenderd, voeg nooit ruwe, onvertrouwde gegevens toe aan het oppervlak zonder deze te escapen, en houd de sandbox van de App strikt. Hana's leveranciersnaamveld is de klassieke fout — onvertrouwde gegevens ingevoegd in een gerenderd oppervlak dat zowel door de gebruiker als het model wordt geconsumeerd, zonder guardrail ertussen.

4. Tasks: Langlopend werk in een nu stateless protocol

Tasks waren experimenteel in de core van 2025-11-25; de release van 2026-07-28 verplaatst ze naar een officiële extensie met een levenscyclus die ontworpen is voor een stateless wereld. Het model wordt door de aanvrager gestuurd: een server kan een tools/call beantwoorden met een task handle in plaats van een direct resultaat, waarna de client het werk aanstuurt met tasks/get, tasks/update en tasks/cancel. (Het eerdere experimentele oppervlak van 2025-11-25 bevatte ook tasks/list en tasks/result; de RC herstructureert de levenscyclus rond get/update/cancel en verwijdert tasks/list, wat niet veilig kan worden afgebakend zodra het protocol stateless is. Beschouw de exacte methodeset als RC-specifiek en controleer de resultaatlevering met de definitieve spec.) Een Task is in feite een kleine duurzame state machine plus een verwijzing naar het resultaat ervan.

Ondersteuning wordt granulair onderhandeld — een peer zegt niet zomaar "Ik ondersteun tasks", maar geeft aan welke verzoeken met taken kunnen worden uitgebreid. De capabilities-map is daar expliciet over:

Tasks-onderhandeling in de 2026-07-28 RC — illustratief; controleer de exacte extensie-ID en het schema met de definitieve spec

De bovenstaande structuur is illustratief voor het extensies-framework van de RC, geen letterlijk schema. De eerdere vorm capabilities.tasks met tasks/list behoorde tot de 2025-11-25 experimentele Tasks API; de RC verplaatst de onderhandeling naar een door reverse-DNS geïdentificeerde extensions-map. Controleer de definitieve identifier en velden met de spec van 28 juli voordat je dit implementeert.

Alles wat niet onder requests staat vermeld, blijft synchroon; een client mag een verzoek dat de server niet heeft geadverteerd niet proberen uit te breiden met een taak. Dit is de schone, MCP-native manier om concurrency af te handelen zonder side channels te verzinnen — en het laat zich combineren met de stateless core omdat de task handle een expliciete, door de server gegenereerde identifier is die de client terugkoppelt, precies het expliciete statuspatroon dat het stateless model aanmoedigt.

5. Een Task observeren: Levenscyclus, voortgang en kosten

Hana's achttien minuten durende blinde vlek is het operationele hart van Tasks. Een langlopende taak die niets retourneert totdat deze klaar is, is een 'black box': je kunt geen voortgang tonen, je kunt de opbouwende kosten niet zien, en je kunt een vastgelopen taak niet onderscheiden van een trage taak. De levenscyclus geeft je de handvatten — de client pollt de status en kan voortgang en tussentijdse updates tonen — maar iemand moet die overgangen vastleggen, de tokens optellen die de taak gedurende de gehele run verbruikt, en dit inzichtelijk maken.

Een taak tot voltooiing aansturen met zichtbaarheid bij elke stap (illustratieve client-loop)

Dit is hetzelfde observability-verhaal als in de rest van de serie, toegepast op een nieuw object. De tracing die een normaal verzoek vastlegt, moet een Task behandelen als een span die gedurende de gehele levenscyclus open blijft, waaraan het token- en kostenverantwoording wordt toegewezen. TrueFoundry's MCP Gateway tracet al elke MCP-servercall en wijst het verbruik toe per gebruiker, tool en team; een Task is diezelfde telemetrie, uitgebreid over een tijdsbestek in plaats van vastgelegd op één enkel moment — wat precies het ontbrekende stukje is in Hana's rapport-tool.

6. Governance: Wie kan Apps en Tasks starten, met welk budget

Het protocol bepaalt hoe Apps en Tasks werken; wie ze mag gebruiken en onder welke limieten, laat het bewust aan jou over. Dat is een governance-gat met concrete vragen. Welke agents of gebruikers mogen überhaupt een langlopende Task starten? Wat is de timeout en het tokenbudget voordat een Task geforceerd wordt geannuleerd — zodat een run van achttien minuten een beleidsbeslissing is en geen ongelukje? Welke tools mogen een App retourneren en welke inhoud mag daarin worden gerenderd?

Illustratief gateway-beleid voor de nieuwe oppervlakken (schema is gateway-specifiek)

Niets hiervan is exotisch; het is hetzelfde mechanisme voor rolgebaseerde toegang (RBAC), budgetten en guardrails dat al wordt toegepast op model-calls en tool-calls, uitgebreid naar twee nieuwe objecten. De reden om dit te centraliseren is dat Apps en Tasks door veel agents over meerdere servers zullen worden gebruikt, en herimplementatie per server of per app is dé manier waarop de achttien-minuten-taak en het ongecontroleerde paneel erdoorheen glippen. Één centraal beleidspunt maakt van "wie kan een Task starten, voor hoe lang, en wat mag er in een App worden gerenderd" één helder antwoord in plaats van vele.

Guardrails maken dit concreet, omdat de gateway de inhoud al controleert op een gedocumenteerde set hooks. De gateway van TrueFoundry biedt er vier — llm_input en llm_output voor modelverkeer, en mcp_pre_tool en mcp_post_tool voor toolverkeer — waaraan een willekeurig aantal validators (PII-detectie, secret scanning, prompt-injection en toxicity-classificaties, SQL-sanitizers, beleidscontroles via Cedar of OPA) kan worden gekoppeld. Deze worden parallel uitgevoerd op hetzelfde verzoek, zodat een input-rail gelijktijdig met de model-call draait en deze kan annuleren voordat er tokens worden gefactureerd als de call wordt geblokkeerd. De operationele discipline die dit veilig houdt in productie is een gefaseerde uitrol — audit (log overtredingen, laat verkeer door), daarna enforce (blokkeer bij fouten, fail-open bij fouten van de provider), en tot slot strict — zodat een storing bij een guardrailprovider nooit het hele pad op dag één platlegt.

7. Migratie: Van experimentele Tasks naar de nieuwe levenscyclus

Als je de experimentele Tasks API uit de 2025-11-25 core hebt geadopteerd, is de overstap naar de extensie een echte migratie, geen naamswijziging. De levenscyclus en methoden zijn geherstructureerd rond tasks/get, tasks/update en tasks/cancel, en de capability-onderhandeling is nu expliciet en granulair. Het goede nieuws is dat het uitfaseringsbeleid in deze release een minimale overlap van twaalf maanden garandeert tussen het aanmerken als verouderd ('deprecated') en het daadwerkelijk verwijderen, zodat het oude oppervlak blijft werken terwijl je overstapt, in plaats van dat het op een specifieke datum zomaar stopt met werken.

Het pad met het laagste risico is het pad dat de stateless-migratie al aanmoedigt: schrijf tools die expliciete handles genereren en vereisen, onderhandel over de Tasks-extensie in plaats van deze aan te nemen, en behandel de release candidate als voorlopig — deze is vastgelegd op 21 mei 2026 en wordt naar verwachting op 28 juli definitief, waarbij de specificatietekst in het validatievenster nog kan wijzigen. Een gateway die tijdens de overlapperiode zowel de experimentele als de extensievormen spreekt, is hier uitermate nuttig, op dezelfde manier waarop het je afschermt tijdens de overgang naar het stateless transport.

8. Waar dit thuishoort: De Gateway als het Governance-punt

Apps en Tasks versterken een patroon dat in deze serie steeds terugkomt: het protocol definieert het mechanisme, en de gateway levert de governance die het protocol open laat. De MCP Gateway bevindt zich al voor elke geregistreerde MCP-server als het punt voor discovery, authenticatie, RBAC en tracing op verzoekniveau — wat precies het oppervlak is waar App-inhoud kan worden gecontroleerd en Task-levenscycli kunnen worden geobserveerd en begrensd.

Concreet betekent dit dat door de App gerenderde inhoud door dezelfde output-guardrails stroomt als elke andere output die aan het model grenst. Een Task wordt getraced als een langlopende span waarvan de tokens en kosten worden toegewezen aan de initiërende agent — met behulp van de discovery, RBAC en observability die de MCP Gateway al biedt, in plaats van op elke server een tweede governancesysteem te monteren. De taakverdeling is bekend: de server implementeert de App of Task; de gateway beheert wie deze mag gebruiken, wat er gerenderd mag worden, hoe lang deze mag draaien en wat het heeft gekost.

9. Veelgestelde vragen (FAQs)

Zijn MCP Apps gewoon een manier om HTML te retourneren?

Nauwkeuriger gezegd: een App breidt een tool uit met een interactieve UI-resource die de host in een gesandboxte iframe rendert — de tool accepteert en retourneert nog steeds JSON, en de App is de optionele schil daarbovenop. Waarom dit van belang is voor governance, is dat de gerenderde inhoud wordt gegenereerd, vaak op basis van onvertrouwde invoer, en via hostgedrag, tool-outputs of door de UI geïnitieerde acties kan terugvoeden in de modelcontext. Dit brengt het binnen het bereik van output-guardrails, in plaats van het te behandelen als een inerte presentatielaag.

Maakt het stateless protocol Tasks overbodig?

Nee — ze lossen verschillende problemen op. Stateless transport betekent dat geen enkel verzoek is gekoppeld aan een specifieke instantie; Tasks modelleren werk dat langer duurt dan een enkele verzoek-respons-cyclus, ongeacht welke instantie elke poll afhandelt. In feite is de task handle precies het expliciete statuspatroon dat het stateless model aanmoedigt: een door de server gegenereerde identifier die de client terugkoppelt, zodat elke instantie over de taak kan rapporteren.

Wat is het grootste nieuwe risico om rekening mee te houden?

Twee dingen. Bij Apps: onvertrouwde inhoud die in het oppervlak wordt gerenderd — behandel dit als output die gecontroleerd moet worden op injection en PII, niet als schadeloze markup. Bij Tasks: onbegrensd langlopend werk — stel een timeout en tokenbudget in zodat een op hol geslagen taak door beleid geforceerd wordt geannuleerd, en trace de levenscyclus zodat het nooit een 'black box' wordt. Beide betreffen governance die je rond de spec toevoegt, niet gedrag dat de spec standaard biedt.

Moet ik nu al migreren?

Plan nu; de release candidate is op 21 mei 2026 vastgelegd en wordt naar verwachting op 28 juli definitief, met 'breaking changes' als je de experimentele Tasks API gebruikte. De uitfaseringsoverlap van twaalf maanden betekent dat er op de datum zelf niets zomaar kapotgaat, maar nieuw werk zou zich moeten richten op de extensie-levenscyclus en expliciet over capabilities moeten onderhandelen. Beschouw de RC als voorlopig tot de definitieve bekrachtiging.

Governance voor Apps of Tasks — gateway of applicatie?

De gateway voor overkoepelende controles: welke agents Apps en Tasks mogen starten, de timeouts en budgetplafonds, output-guardrails op gerenderde inhoud, en het tracen van de levenscyclus — uniform toegepast op elke MCP-server. De applicatie blijft eigenaar van de domeinlogica van wat de App toont en wat de Task doet, omdat daarvoor kennis nodig is die de gateway niet heeft.

De release van 2026-07-28 staat bekend om het overstappen op stateless werken, maar Apps en Tasks zijn het onderdeel dat verandert wát je bouwt. Ze voegen een gerenderd oppervlak en een langlopend oppervlak toe, waarbij de spec je het mechanisme geeft en de governance open laat. Dicht dat gat bij de gateway — controleer wat er gerenderd wordt, begrens wat er draait, trace beide — en Hana's goede demo verandert in een goed productiesysteem.

Als de gateway de plek is waar je deze oppervlakken beheert, is het handig dat hetzelfde controlevlak ook de plek is waar de agents draaien die ze gebruiken. TrueFoundry's AI Gateway is het centrale toegangspunt voor model-, MCP- en toolverkeer, en de Agent Harness is de runtime die de plan-act-observe-loop, sandboxing, goedkeuringen en tracing van een agent daarbovenop orchestreert. Zo worden de App-inhoud die een agent rendert en de Tasks die deze start, gecontroleerd, begrensd en getraced door hetzelfde vlak dat de agent uitvoert, in plaats van door een governancelaag die er pas achteraf op is gemonteerd.

Referenties

• Model Context Protocol — De 2026-07-28 release candidate (Extensies, MCP Apps, Tasks)
• MCP 2025-11-25 — Experimentele Tasks API (het eerdere oppervlak; de 2026-07-28 RC herstructureert dit als een extensie)
• TrueFoundry — MCP Gateway (discovery, RBAC, observability)
• Onze Prompt Injection en OpenTelemetry voor LLMs artikelen — output-guardrails en tracing, toegepast op de nieuwe oppervlakken.

Northwind en Hana zijn illustratief. De details over MCP Apps en Tasks zijn ontleend aan het officiële Model Context Protocol 2026-07-28 release-candidate materiaal en gerelateerde artikelen van eind mei 2026; de RC is op 21 mei vastgelegd en wordt naar verwachting op 28 juli 2026 bekrachtigd. De specificatietekst kan nog veranderen, dus beschouw protocolspecificaties — zoals methodenamen, capability-structuren en levenscyclusstatussen — als voorlopig en controleer ze met de definitieve spec. Codevoorbeelden zijn illustratief voor de gedocumenteerde patronen en niet gekopieerd uit een referentie-implementatie. Mogelijkheden van TrueFoundry zijn samengevat uit openbare productdocumentatie en ontwikkelen zich continu verder.

‍