Met MCP Tasks geeft een trage tool-aanroep direct een duurzame handle terug in plaats van te blokkeren, zodat werk van enkele minuten timeouts, verbroken verbindingen en herstarts overleeft. Wat de meeste uitleg nog steeds niet vermeldt: het ontwerp is op 28 juli 2026 wezenlijk veranderd. Tasks verliet de experimentele protocolkern, werd de extensie io.modelcontextprotocol/tasks, en kantelde van client-gestuurd naar server-gestuurd. Bouwde u tegen de versie van november 2025, dan is het meeste dat u schreef verplaatst.
Wat is er op 28 juli 2026 werkelijk veranderd aan MCP Tasks?
De maintainers vatten het in één zin samen in de release notes van 2026-07-28: Tasks gaat uit de experimentele kern naar de tasks-extensie, met een op polling gebaseerde tasks/get en een nieuwe tasks/update, en wijzigingsmeldingen verhuizen van het oude HTTP GET-endpoint naar één subscriptions/listen-stroom. Achter die zin zitten vier losse breuken.
- Wie beslist. In het ontwerp van 2025 vroeg de aanroepende partij zelf om een task, door een task-object met een ttl aan de params toe te voegen, en gaf elke tool aan of taskgebruik verboden, optioneel of verplicht was. In de extensie beslist de server, per verzoek. Een client meldt zijn ondersteuning één keer aan, in het extensions-veld van de capabilities die hij in elk verzoek in _meta meestuurt, en moet daarna beide antwoordvormen aankunnen. De Tasks-documentatie is helder over het doel: geen opwarmronde per tool, geen vlaggetje per verzoek.
- Wat u terugkrijgt. Een taskantwoord is herkenbaar aan resultType: "task" en bevat een taskId, een beginstatus, een ttlMs en een geadviseerde pollIntervalMs. De task moet duurzaam zijn aangemaakt vóórdat dat antwoord vertrekt. Dat is een echte eis aan uw server, geen detail.
- Hoe u het antwoord ophaalt. Het oude ontwerp had een blokkerende tasks/result die het antwoord openhield tot de task klaar was. De extensie kent drie methoden en geen enkele blokkerende: tasks/get, tasks/update en tasks/cancel. Polling is de standaard.
- Hoe invoer onderweg werkt. Heeft een task een bevestiging nodig, dan gaat hij naar input_required en bevat het tasks/get-antwoord een inputRequests-map. De client antwoordt met tasks/update. Geen tweede verbinding, geen ongevraagde berichten van server naar client.
De vijf statussen overleefden de herschrijving: working, input_required, completed, failed en cancelled, waarvan de laatste drie eindstatussen zijn. Annuleren is coöperatief, en dat leest u het best twee keer. tasks/cancel legt een intentie vast. De server bevestigt die en kan het werk alsnog afmaken.
Waarom kantelde het ontwerp van client-gestuurd naar server-gestuurd?
Omdat de sessies verdwenen zijn, en vrijwel elke bespreking van Tasks behandelt dat als een los verhaal. Het is hetzelfde verhaal. De kop van de release van 28 juli is de stateless kern: de handshake met initialize en initialized en de Mcp-Session-Id-header zijn geschrapt, zodat elk verzoek achter een gewone round-robin load balancer op elke serverinstantie kan landen.
Een blokkerende tasks/result overleeft dat niet. Een antwoord openhouden tot een klus af is, is sessiestatus met een andere jas aan: het bindt een client voor de duur van het werk aan één proces, precies wat deze release wilde opruimen. Zodra u het opengehouden antwoord schrapt, is polling geen ontwerpvoorkeur meer. Het is het enige mechanisme dat nog werkt wanneer opeenvolgende verzoeken bij verschillende instanties uitkomen. Dezelfde logica verklaart waarom de taskSupport-verklaring per tool verdween: die stond in een tools/list-antwoord dat clients nu juist met een ttlMs mogen cachen, en daarmee was het geen betrouwbare plek meer om iets te onderhandelen.
Er is een tweede gevolg dat makkelijk over het hoofd wordt gezien en duur is om laat te ontdekken. MCP kent nu twee verschillende input_required-paden. Multi Round-Trip Requests (SEP-2322) geven resultType: "input_required" terug, waarna de client de oorspronkelijke aanroep opnieuw doet met de antwoorden in inputResponses. Tasks geven de status input_required op een handle, waarna de client met tasks/update antwoordt. Dezelfde woorden, een andere besturing, en andere kosten bij falen: MRTR gooit het halve werk weg en speelt de aanroep opnieuw af, terwijl een task de berekening op de server in leven houdt. Bouwt uw tool negentig seconden aan iets voordat er een mens moet aftekenen, dan is dat het verschil tussen één run en twee.
Wat kost polling u werkelijk?
De zinsnede in de roadmap om op te letten is dat server-initiated events moeten voorkomen dat clients blijven pollen op resultaten. Hieronder de rekensom daarachter, met de aannames erbij zodat u uw eigen cijfers kunt invullen.
Neem een middelgrote belasting: 40 langlopende klussen per werkdag, gemiddeld 12 minuten per stuk, en een server die een pollIntervalMs van 5000 adviseert. Twaalf minuten is 720 seconden, dus elke klus kost 144 polls. Dat zijn 5.760 polls per dag, ofwel ruwweg 126.700 in een werkmaand van 22 dagen. Elk daarvan is onder de stateless kern een volledig HTTP-verzoek, zelfbeschrijvend, met eigen capabilities in _meta en eigen Mcp-Method- en Mcp-Name-headers, en elk krijgt zijn eigen autorisatiecontrole.
Dezelfde maand via push zou ongeveer 880 meldingen kosten, één per klus plus wat marge. Dat is een daling van ruwweg 99,3 procent in verkeer op de besturingslaag, voor exact dezelfde informatie. Anders gezegd: het protocol besteedt vandaag 144 geauthenticeerde retourvluchten om één bit door te geven, namelijk of de klus af is.
Twee eerlijke kanttekeningen. Polls hoeven geen modeltokens te kosten, want een goed gebouwde clientlus handelt ze af zonder omweg langs het taalmodel. Dit is dus een infrastructuurrekening, geen inferentierekening. En 126.700 verzoeken per maand is voor de meeste hosting geen groot getal. De kosten zitten aan de randen: prijzen per verzoek, rate limiters die op menselijk tempo zijn ingericht, tokencontroles bij elke aanroep, en logvolume waarin de nuttige gebeurtenissen onvindbaar worden. Ons artikel over MCP draaien in productie gaat in op waar die rekeningen echt landen.
Wat gaan webhooks en channels veranderen?
Op 22 augustus 2026 publiceerden de Core Maintainers een nieuwe MCP-roadmap met vijf prioriteiten: agentic messaging primitives, unificatie van het HTTP-native transport, agentidentiteit en enterprise-waardige beveiliging, betere primitieven, en de ontwikkelaarservaring van de SDK's. Tasks valt onder de eerste.
Het werk dat daar genoemd wordt is server-initiated events, concreet webhooks en channels, onder leiding van de Triggers and Events Working Group, plus een compositiereview over de werkgroepen Agents, Transports en Triggers and Events heen, plus het rijpen van de Tasks-extensie zodat die naar de specificatie kan verhuizen. Lees die laatste zinsnede nauwkeurig, want daar zit het praktische gevolg: Tasks staat vandaag niet in de specificatie. Het is een extensie die de maintainers willen promoveren, en de roadmap beslaat zes tot twaalf maanden.
In de huidige specificatie zit al een deel van het antwoord. Servers mogen notifications/tasks sturen, en clients schrijven zich daarop in via subscriptions/listen, een langlopende stroom waarin de client precies benoemt welke meldingstypen hij wil en de server niets anders mag sturen. Elke melding draagt de volledige taskstatus, dus een extra tasks/get is niet nodig. De documentatie noemt polling nog steeds de standaard, en dat is de eerlijke positie zolang de clientondersteuning dun is.
Kunt u vandaag veilig op de Tasks-extensie bouwen?
Voor servers wel, met één ontwerpregel. Voor clients: controleer het voordat u iets aanneemt. Het bewijs wijst twee kanten op en dat is het waard om uit te schrijven in plaats van een kant te kiezen.
- Vóór: SEP-2663 heeft de status Final bereikt op de Extensions Track. Tasks is bijgedragen door AWS, dat Amazon Bedrock AgentCore noemt als plek waar de nieuwe specificatie draait, volgens de leveranciersverklaringen in de releasepost, en Microsoft Foundry en FastMCP 4.0 noemden bij de lancering allebei ondersteuning voor achtergrondtaken. Dit is geen voorstel zonder implementaties.
- Tegen: Tasks is een extensie en geen onderdeel van de specificatie, en juist dat wil de roadmap veranderen. De ext-tasks-repository noemt de eigen status op GitHub nog steeds experimenteel. En de door de gemeenschap bijgehouden ondersteuningsmatrix voor extensies volgt MCP Apps, OAuth Client Credentials en Enterprise-Managed Authorization. Tasks staat er helemaal niet op, voor geen enkele client.
Die afwezigheid weegt zwaarder dan het lijkt. Extensies zijn aan beide kanten opt-in: een server moet controleren of de client de extensie heeft aangemeld voordat hij een task teruggeeft, en mag er nooit één teruggeven aan een client die dat niet deed. Een server die alleen asynchroon kan werken, faalt dus botweg tegen een groot deel van het ecosysteem. De ontwerpregel volgt daaruit: bouw eerst het synchrone pad en geef een task terug als upgrade, wanneer de client zegt er één aan te kunnen.
Waar komt langlopend werk in het Nederlandse mkb eigenlijk voor?
Voor een bedrijf van 20 tot 50 medewerkers is de eerlijke lijst kort, en niets ervan is exotisch. 's Nachts een batch inkoopfacturen uitlezen. Een nachtelijke synchronisatie van verrijkte gegevens naar Exact Online of AFAS. Een archief opnieuw classificeren nadat iemand het rekeningschema heeft aangepast. Een maandrapport dat drie systemen leest en elf minuten nodig heeft. In al die gevallen heeft een synchrone tool-aanroep de verkeerde vorm, en lossen de meeste teams dat vandaag op door de agent een klus te laten starten en de gebruiker een link te geven om later te kijken. Dat is een zelfgebouwde task, zonder enige garantie op duurzaamheid.
Het vierde geval is het interessantste: elke stap waarin een mens moet aftekenen voordat de automatisering verdergaat. input_required is de protocolversie van een controle die uw financiële afdeling allang uitvoert. Wij schreven eerder over het vierogenprincipe, audit trails en idempotentie als de drie dingen die bepalen of een financiële automatisering controleerbaar is, en Tasks is de eerste keer dat MCP een eigen plek biedt voor de eerste daarvan. De task houdt het werk vast, de persoon keurt goed, de run gaat verder op dezelfde handle, en het taskId geeft uw audit trail iets om naar te verwijzen.
Voor de kleinste categorie, 1 tot 10 medewerkers, is het nuttige antwoord meestal nee. Bestaat uw automatisering uit één n8n-workflow die één API aanroept, dan hebt u al een wachtrij en levert een protocolextensie u niets op. Tasks verdient zijn complexiteit zodra meerdere clients dezelfde server aanroepen, of zodra een klus de sessie overleeft die hem startte. Die drempel is de trigger, niet de bedrijfsgrootte.
Wat wij vandaag zouden bouwen
Een regel op basis van looptijd, per tool toegepast en niet per server:
- Onder ongeveer tien seconden: een gewone synchrone tools/call. Grijp niet naar Tasks.
- Tien seconden tot ruwweg twee minuten: blijf synchroon en stuur voortgangsmeldingen op het oorspronkelijke verzoek. De meeste tussenliggende netwerklagen accepteren dat; veel meer accepteren ze niet.
- Minuten tot uren, of alles wat een herstart van de client moet overleven: Tasks, met een duurzame opslag erachter. Taskstatus kan niet in het geheugen hangen aan een verbinding, want juist die verbinding verdwijnt.
- Alles wat wacht op een menselijk besluit: Tasks, hoe snel de berekening ook is. Het is het enige pad dat het werk in leven houdt terwijl iemand nadenkt.
Twee implementatienotities die u een slechte week besparen. Geef het aanmaken van een task een idempotentiesleutel afgeleid van het verzoek, want een client die na een timeout opnieuw probeert, start anders een tweede klus waarvoor u nu dubbel betaalt. En bind elk taskId aan de autorisatiecontext die het aanmaakte, zodat tasks/get, tasks/update en tasks/cancel voor ieder ander falen alsof de task niet bestaat. Een taskId is een capability handle, en het behandelen als een gewone identificatie is precies hoe een multi-tenant server resultaten tussen klanten laat weglekken.
Het bredere punt voor wie koopt in plaats van bouwt: vraag een leverancier welke specificatieversie zijn MCP-server spreekt en of hun client de tasks-extensie aanmeldt. Die twee antwoorden zeggen meer over de vraag of een koppeling volgend jaar nog werkt dan welke functielijst dan ook. Weegt u af wat een werkende agentkoppeling inhoudt, dan laat onze pagina over AI-agents laten ontwikkelen zien hoe wij er één afbakenen, en wat een AI-project kost gaat over de begroting.
