Waarom MCP altijd een slecht idee was

Recentelijk heb ik een dagvullend evenement bezocht dat in het teken stond van de nieuwste en beste ontwikkelingen in de wereld van MCP. Hoewel alle presentatoren geweldig waren en gepassioneerd leken over hun werk, ben ik eerlijk gezegd klaar met MCP. Het is een verschrikkelijk protocol dat is gebouwd voor een tijd waarin LLM's minder intelligent waren, en we zijn er inmiddels aan ontgroeid.

Een korte geschiedenis

MCP werd in november 2024 uitgebracht door het team van Anthropic als een protocol dat bedoeld was om agents te helpen verbinding te maken met externe services en databronnen.[^1] De modellen van die tijd waren nog relatief primitief, althans in vergelijking met wat we nu hebben. We hadden toen nog geen Claude Code en algemene agentische workflows waren veel minder betrouwbaar.

Gebruikers begonnen het nut in te zien van het geven van toegang tot externe services aan hun AI-modellen. Dit maakte een niveau van productiviteit mogelijk dat we daarvoor niet hadden gezien. We zagen een explosie in de adoptie van MCP, wat samenviel met een vergelijkbare, zo niet explosievere, groei in de adoptie van LLM's binnen de economie.

In de loop van de tijd bleef MCP evolueren onder het beheer van Anthropic, voordat het in 2025 werd gedoneerd aan de Agentic AI Foundation, onderdeel van de Linux Foundation.[^2]

Het MCP-industriecomplex

Door de enorme groei in adoptie begonnen gebruikers veel MCP-servers aan hun setup toe te voegen, waardoor ze tegen het probleem van 'context bloat' aanliepen. Elke server kwam met meerdere tools, elk met een eigen schema, wat de context van al deze modellen begon te overbelasten. Harness-ontwikkelaars vonden hier diverse trucs voor, waaronder generieke search/execute-patronen die nu worden aangeboden door platforms zoals Composio, MintMCP en Pipedream. Zij lossen effectief het probleem op door één centrale plek te bieden voor inloggegevens van diverse externe services en de agent een minimale set tools te geven (om context bloat te verminderen) waarmee deze diensten kunnen worden benaderd. Ik wil duidelijk maken dat dit op de korte termijn een goede zaak is.

Wat we echter niet in overweging hebben genomen, of wellicht hebben genegeerd bij alles wat we rondom MCP hebben gebouwd, is dat de modellen beter worden. We hebben nu complete systemen die gewijd zijn aan het monitoren van MCP-servers, het controleren of de reacties goed zijn, het garanderen dat agents eenvoudig toegang hebben tot de tools, het uitzoeken van schema's en het bepalen wat we agents moeten geven zodat ze op het juiste moment de juiste keuze kunnen maken.

Verrassing: de grote labs hadden gelijk

De modellen zijn verbeterd. Ze zijn nu in staat om code uit te voeren op een computer, te redeneren over grote codebases en over het algemeen veel autonomer te handelen dan ooit tevoren. Een groot deel van dat werk bestond uit het schrijven en uitvoeren van scripts voor programmeerdoeleinden. Een neveneffect hiervan (is het dat wel?) is dat ze nu in staat zijn om API's direct aan te roepen. Ze kunnen scripts schrijven, meerdere verschillende services combineren en API's aanroepen die ze nog nooit hebben gezien, allemaal in nuttige workflows met minimale interventie van de gebruiker.

LLM's zijn hier zo goed in geworden dat Cloudflare zelfs Code Mode lanceerde: een betere manier om MCP te gebruiken door LLM's de verschillende aanroepen te laten samenvoegen in scripts die in een sandbox kunnen worden uitgevoerd.[^3]

Maar wat nog beter is: LLM's hebben ontdekt hoe ze het --help commando kunnen gebruiken om CLI's (Command Line Interfaces) te ontdekken. Hierdoor hebben ze geen MCP-servers meer nodig om toegang te krijgen tot veel services die beschikbaar zijn via gedocumenteerde API's of CLI's. De meeste remote-service MCP-servers zijn uiteindelijk slechts wrappers rond API's die al bestonden.

Wat nu?

We verwijderen het grootste deel van onze MCP-servers. Dat is alles. Agents met terminal-toegang kunnen de meeste MCP-servers vervangen en zijn vaak krachtiger. Er zijn nog steeds enkele problemen, zoals CLI's die machineleesbare reacties (JSON/XML, etc.) teruggeven—die vaak erg uitgebreid zijn en veel tokens verbruiken—maar we hebben manieren om dit op te lossen.

Veel van het alternatief bestaat al: gedocumenteerde HTTP API's, standaard content-onderhandeling en volwassen authenticatiemechanismen.

We zouden moeten beginnen met het standaardiseren van de manier waarop agents direct HTTP API's gebruiken. Agent-clients zouden bijvoorbeeld headers kunnen toevoegen om zichzelf als agents te identificeren, waarna servers hen automatisch responsdata kunnen sturen als Markdown of tekst in plaats van HTML of uitgebreide JSON.

Enkele concrete voorbeelden

De Accept Markdown Header Een groeiend aantal LLM-vriendelijke servers, vooral tekstzware sites zoals documentatiepagina's, respecteren de Accept: text/markdown header. Deze servers kunnen automatisch een gerenderd Markdown-bestand sturen in plaats van de HTML-respons die ze normaal gesproken zouden sturen. Het mediatype zelf is gestandaardiseerd en het gebruik ervan voor agent-georiënteerde content-onderhandeling wordt steeds populairder.

Documentatiesites die de Accept-Language Header gebruiken Onlangs heeft een Vercel-engineer opgeroepen tot harnesses die de voorkeursprogrammeertaal van de client versturen, zodat documentatiesites specifiekere voorbeelden kunnen serveren. Door bijvoorbeeld 'Python' toe te voegen, kan de site prioriteit geven aan documentatie voor de Python SDK in plaats van iets algemeens te sturen. Tobi Lutke van Shopify was zo enthousiast over dit idee dat het nu wordt geïmplementeerd in de Shopify-documentatie.

Malte Ubl (@cramforce): Verzoek aan harnesses: Ik vind het geweldig dat jullie nu Accept: text/markdown sturen. Het volgende is: zet de programmeertaal die je verkiest in de Accept-Language header.
Tobi Lutke (@tobi): Geweldig idee. Wordt ondersteund in de Shopify-documentatie.

Slotbeschouwingen

Standaardisatie rondom gemeenschappelijke protocollen heeft het internet laten groeien tot wat het vandaag is. MCP is nu een protocol van een vervlogen tijdperk. Agents zijn slim en in staat om scripts te schrijven en precies te vragen wat ze willen. In plaats van verder het konijnenhol van MCP in te duiken, zeg ik dat het tijd is om het 'end-of-life' te verklaren en direct te vertrouwen op HTTP API's en CLI's waar deze al de nodige interface bieden.

***

Bronverwijzingen

[^1]: Anthropic, “Introducing the Model Context Protocol”, 25 november 2024. [^2]: Anthropic, “Donating the Model Context Protocol and establishing the Agentic AI Foundation”, 9 december 2025. [^3]: Kenton Varda and Sunil Pai, “Code Mode: the better way to use MCP”, Cloudflare Blog, 26 september 2025.