Na het bouwen van zeven MCP-servers met 52 tools over negen externe API's worden de beperkingen van het protocol scherp. MCP blinkt uit in het verbinden van agents met tools. Het helpt agents nog niet begrijpen wat die tools betekenen, of veilig handelen op basis van wat ze begrijpen.
Dit zijn de zes veranderingen, gegrond in productie-ervaring en niet in speculatie, die de ondergrens zouden verhogen voor elke server in het ecosysteem.
1. Slimmere tool-discovery
Vandaag dumpt elke verbonden MCP-server al zijn tools tegelijk in de context van de agent. Voor een enkele server met 10 tools is dat prima. Voor een developer in een IDE met 10 servers tegelijk verbonden? Dat zijn 100+ tool-descriptions die vechten om context.
Dit heeft een remmend effect op metadata-investeringen: waarom 200 regels rijke domeinkennis per tool schrijven als de client alles gaat overspoelen?
De spec heeft een discovery-laag nodig, een soort DNS voor tools. Laat servers toolgroepen declareren met korte samenvattingen. De client presenteert groepen aan het model, het model selecteert de relevante groep, en alleen die tooldefinities worden geïnjecteerd. Eerst resolven, dan laden.
2. Uitbreidbare metadata zonder context-overstroming
Alle metadata gaat momenteel in tool-descriptions en inputschema-beschrijvingen, beide verbruiken contexttokens bij elke aanroep. Er is geen mechanisme voor metadata die de agent on-demand kan opvragen.
Een tool zou 200 regels velddocumentatie, cross-referentietabellen en querystrategiegidsen als gestructureerde metadata kunnen declareren. De client laadt standaard de toolnaam en korte beschrijving, maar injecteert de volledige metadata alleen wanneer het model aangeeft die tool te willen aanroepen.
Dit zou de afweging tussen rijke documentatie en context-efficiëntie elimineren. Een afweging die server-auteurs momenteel dwingt kritieke domeinkennis in kunstmatig korte beschrijvingen te persen.
3. Resources die daadwerkelijk werken
MCP Resources zijn het antwoord van de spec op referentiedocumentatie: statische of dynamische content die agents kunnen opvragen om hun redenering te informeren. In theorie perfect voor domeingidsen en veldwoordenboeken.
In de praktijk toont geen enkele geteste client betrouwbaar resources aan agents. Claude Desktop toont ze in een sidebar, maar agents vragen ze niet op. Claude Code en Cursor negeren ze volledig. Ik heb resources gebouwd, getest en verwijderd nadat validatie nul agent-geïnitieerde verzoeken liet zien.
Om resources te laten werken, moeten clients óf: automatisch relevante resource-content injecteren wanneer een gerelateerde tool wordt geselecteerd, servers toestaan resources te markeren als vereiste context voor specifieke tools, of het model een expliciet get_resource-primitief geven waarop het getraind is.
4. Eersteklas feedbackloops
De huidige spec kent geen concept van agent-naar-server feedback. Elke interactie is request-response: roep een tool aan, krijg data terug, ga verder. Geen standaard manier voor agents om verwarring te melden, datakwaliteitsproblemen te flaggen, of aan te geven welke calls niet nuttig waren.
Ik loste dit op met een custom report_problem-tool en queryIntent-parameters op elk inputschema. Dit werkt, maar het is een workaround. De spec zou feedback als eersteklas primitief moeten ondersteunen: een gestandaardiseerde manier voor agents om tool-calls te annoteren met intent, tevredenheid en aangetroffen problemen. Server-auteurs zouden zich kunnen abonneren op feedback-events en metadata iteratief verbeteren.
5. Agent-training op MCP-patronen
Misschien zou de meest impactvolle verandering niet in de spec plaatsvinden maar in modeltraining. Huidige modellen zijn niet getraind op rijke MCP-interacties. Ze weten niet dat een WHEN TO USE-blok anders geparsed moet worden dan een generieke API-beschrijving. Ze begrijpen niet dat .describe()-annotaties op outputschemavelden er zijn om gelezen en gebruikt te worden.
Als modelproviders rijke MCP-serverinteracties in hun trainingsdata zouden opnemen (tool-descriptions met domeinmetadata, multi-tool sequenties met cross-referenties, feedbackloops met intentparameters), zouden agents natuurlijk de metadata benutten die server-auteurs investeren in het schrijven. De metadata is al machine-leesbaar. De modellen moeten alleen leren het te lezen.
6. Scoped schrijfrechten voor MCP Apps
Naarmate servers evolueren van read-only naar interactieve applicaties, worden schrijfoperaties onvermijdelijk. Maar de spec biedt geen mechanisme om een schrijftool te beperken tot een specifieke interactiecontext. Als een server een POST-tool blootstelt, kan elke verbonden agent het op elk moment aanroepen.
Ik ontwierp een workaround: het WriteIntent-patroon. De agent roept een model-zichtbare "open"-tool aan die een server-side intent aanmaakt. De daadwerkelijke mutatie wordt uitgevoerd door een aparte "commit"-tool geregistreerd met visibility: ["app"], verborgen voor de agent, alleen aanroepbaar door het MCP App-formulier. De intent is user-bound, resource-scoped, one-shot, tijdsgebonden en gevalideerd met getypeerde schema's.
De spec zou dit moeten formaliseren: een manier om schrijftools te scopen naar specifieke MCP-apps, zodat een tool gemarkeerd als write-only-via-app alleen via een gevalideerde formulierinteractie kan worden aangeroepen.
Alle zes aanbevelingen delen een gemeenschappelijk thema: de spec is ontworpen voor transport, maar de echte uitdaging is kennislevering en veilige interactie. Het aanpakken van deze gaten op framework-niveau zou de ondergrens verhogen voor elke server, niet alleen die gebouwd door teams die bereid zijn 40 uur in metadata-engineering te investeren.
Voor de volledige context achter elke aanbeveling, inclusief het productie-bewijs en implementatiepatronen, download het practitioner report.