Stop met bouwen rond het model. Bouw voor MCP.
Na het opleveren van negen productie MCP-servers bij één mid-sized engineering-bedrijf (gebonden aan Claude in ons geval, hoewel alles hieronder net zo goed werkt voor GPT, Gemini of welk frontier-model dan ook dat MCP spreekt), hier is wat ik niet heb gebouwd: agent-frameworks, RAG-pipelines, vector databases, orkestratie-platforms, of welke andere laag dan ook waar de AI-industrie op staat dat je nodig hebt.
Wat ik in plaats daarvan heb: een frontier-model, MCP-servers en goed geschreven tool-descriptions. Dat is alles. En het werkt: meetbaar, dagelijks, door het hele bedrijf.
In 2026 is MCP geen niche-bet meer. Het passeerde ongeveer 97 miljoen maandelijkse SDK-downloads, en OpenAI, Google, Microsoft en Anthropic hebben het allemaal in hun producten geïntegreerd. De protocol-vraag is beslist. En omdat elk frontier-model MCP nu via dezelfde interface consumeert, is de model-vraag ook beslist. Kies er één en de architectuur verandert niet. Wat nog ter discussie staat is of je er nog iets bovenop nodig hebt.
Het model is de agent. Het framework is overhead.
De formulering "je hebt een agent-framework nodig" verdoezelt een simpelere waarheid: het model is de agent. Het leest tool-descriptions. Het kiest welke tool aan te roepen. Het sequencet de calls. Het interpreteert de resultaten. Dat is leerboek-agentgedrag, ingebakken in elk frontier-model dat MCP spreekt.
Wat bedrijven je daarbovenop verkopen is framework rond de agent: orkestratie-logica, retrieval-pipelines, prompt-managers, observability-lagen. Elk van die producten lost een echt probleem op in een bepaalde context. Maar in een mkb met een overzichtelijke set belangrijke databronnen zijn die contexten meestal niet aan de orde.
| Wat ik gebruik | Wat ik oversla |
|---|---|
| Een frontier-model (Claude in mijn geval; wissel naar wens) | LangChain + LangGraph + LangSmith-stack |
| MCP-servers (custom, goed-getypeerd) | Multi-agent-orkestratie (CrewAI, Microsoft Agent Framework, OpenAI Agents SDK) |
| Tool-descriptions als interface | Vector DBs, embedding-pipelines, agentic-retrieval frameworks (LlamaIndex) |
| Domeinkennis in de schemas | Met de hand samengestelde knowledge graphs naast de tool |
| Cross-source compositie via tool-ontwerp | Workflow-orkestratie-platforms |
| Productie-telemetrie als feedback-loop | Agent-observability-stacks (LangSmith, LangFuse, Arize Phoenix) |
Elke rij rechts is een betaalde productcategorie. Elke rij links is het model, het protocol, of werk dat ik één keer doe en hergebruik.
Hoe "bouwen voor MCP" er in de praktijk uitziet
Een goed ontworpen MCP-server vraagt het model niet om uit te zoeken wat de data betekent. Hij vertelt het model wat de data betekent in de tool-description zelf.
Het contrast speelt zich af op elk niveau. Een slechte tool zegt: "haal data op uit de ERP." Een goede tool zegt: "begin altijd met summaryOnly=true. Actieve projecten verzamelen duizenden records. Typecodes bepalen welke velden gevuld zijn. Gebruik get_budget voor geplande kosten, deze tool voor werkelijke kosten."
De eerste versie dwingt het model om bij elke call opnieuw een query-strategie te bedenken. De tweede geeft het model bij elke call een query-strategie mee. Het verschil tussen die twee servers, in productie, is of zakelijke gebruikers het resultaat daadwerkelijk gebruiken.
Dit is het werk dat teams overslaan als ze grijpen naar frameworks. De complexiteit is grotendeels zelf-veroorzaakt. Die ontstaat omdat niemand opschreef wat de tools betekenen. Dezelfde tekortkoming is waarom 97% van de in productie geanalyseerde MCP tool-descriptions minstens één kritieke smell bevat.
Eén server kan veel bronnen samenbrengen
Het meest gehoorde bezwaar ("maar je hebt toch orkestratie nodig om data uit meerdere systemen te combineren?") gaat ervan uit dat orkestratie in een apart framework moet leven. Dat hoeft niet.
Eén van mijn MCP-servers combineert vijf heterogene bronnen achter één interface: een third-party meterdata-aggregator, een publieke weer-API, een overheids-gebouwregister, de bedrijfs-ERP en een IoT-gebouwautomatiseringsplatform. Geen agent-dance. Geen retrieval-pipeline. Alleen getypeerde tools met descriptions die uitleggen wanneer elke bron van toepassing is en hoe ze samenhangen.
Het model figureert de compositie uit omdat de tool-descriptions hem de relaties vertellen. Het patroon werkt over negen productie-servers heen die ERP, BIM, vloot, calculaties, gebouwautomatisering, energie en operationele logs dekken. Effectief het hele operationele oppervlak van één bedrijf, aanspreekbaar via tool-descriptions, consumeerbaar door welk MCP-sprekend model dan ook.
Tools abstraheren alles eronder
Het model ziet nooit hoe de data wordt opgehaald. Binnen één MCP-server roepen individuele tools aan wat het onderliggende systeem ook maar spreekt: REST voor SaaS-producten, GraphQL voor interne API's, directe SQL tegen het data warehouse, JSON-bestanden op disk, SOAP-envelopes voor legacy-systemen. De tool retourneert getypeerde records; de protocol-heterogeniteit blijft binnen de tool.
Dat is de abstractielaag waar de data-fabric- en iPaaS-industrieën premium prijzen voor vragen om te bouwen. MCP-tools doen het al, één tool tegelijk, in welke taal de data dan ook leeft, zonder centrale pipeline. De keuze van backend propageert niet; kies wat past bij het onderliggende systeem, en de model-interface blijft identiek.
Zelfs SQL wordt hanteerbaar. Directe SQL vanuit een LLM is gevaarlijk omdat het model kan worden verleid tot destructieve queries. Maar SQL binnen een getypeerde MCP-tool (waar de server SQL bouwt vanuit schema-gevalideerde parameters, de connectie als read-only role draait, en de corporate IdP bepaalt wie hem mag aanroepen) is gewoon een function call. Elke waarde die niet overeenkomt met het JSON-schema van de tool wordt aan de protocol-grens afgewezen, voordat de code van de tool überhaupt draait.
Dit is geen theorie. Eén van mijn servers is 100% SQL achter een query-endpoint, voor calculatie-data. Elke tool vertaalt een getypeerd agent-request naar een SQL-query: het model geeft schema-gevalideerde parameters door, de server bouwt en draait de query, getypeerde records komen terug. Het model ziet nooit SQL. De connectie draait als read-only role, en toegang wordt geregeld door dezelfde IdP-rollen die elk ander systeem regelen.
Ik heb hem in één dag gebouwd. De calculatie-expert die de onderliggende data beheert heeft hem gevalideerd, en hij ontsluit nu al alle data die dat team nodig heeft. Als je het patroon eenmaal door hebt, is een nieuw domein een dag werk, geen kwartaalproject.
Waarom het mkb de sweet spot is
Dit argument heeft grenzen. Op Fortune 500-schaal (honderden heterogene systemen, multi-tenant SaaS, bergen ongestructureerde documenten) heb je misschien echt retrieval-pipelines en orkestratie nodig. De complexiteit is reëel omdat de scope reëel is.
Maar mkb-bedrijven hebben iets wat Fortune 500 niet heeft: een overzichtelijke set belangrijke databronnen. Vijf tot twintig kernsystemen. Een handvol domeinexperts die een middag met je kunnen zitten en kunnen vertellen wat de data daadwerkelijk betekent. Dat is de hele voorwaarde voor een goed gebouwde MCP-server.
Als jouw bedrijf in één kantoorgebouw past en minder dan twintig belangrijke systemen heeft, ben jij degene voor wie dit bedoeld is. Je hebt vrijwel zeker het meeste niet nodig van wat de AI-industrie je probeert te verkopen.
Wat "het platform" eigenlijk is
Let op wat ontbreekt in de tabel hierboven: een platform. Er zit geen "AI-platform" in de stack. Alleen een frontier-model, MCP-servers, en de corporate identity-laag waar het bedrijf al voor betaalt. Wissel het model (Claude vandaag, Gemini morgen, GPT volgend kwartaal) en de rest van de stack blijft identiek.
Dat laatste stuk is wat van negen MCP-servers iets maakt dat een enterprise kan draaien. Geen AI-specifieke identity-laag. Die het bedrijf al heeft. In een Microsoft-shop is dat Entra ID met RBAC. In andere shops Okta, Google Cloud Identity, of welke OAuth 2.1-provider dan ook. MCP-servers authenticeren tegen de bestaande IdP, scopen tool-toegang per rol, en loggen elke call naar dezelfde audit trail die elk ander corporate systeem al gebruikt.
De implicaties:
- Een monteur ziet alleen zijn eigen tijdboekingen en toegewezen projecten.
- Een controller ziet geaggregeerde financiële cijfers, geen ruwe loonadministratie.
- Een gast-gebruiker ziet niets.
Elke actie is toe te wijzen aan een named identity in dezelfde audit log als elk ander systeem. Dat is het hele enterprise-AI-beveiligingsmodel. Geen prompt-firewall-vendor. Geen AI-specifiek governance-platform. Geen model-gateway. Alleen de access-control-infrastructuur die het bedrijf al draait, afgedwongen op de MCP-tool-grens. Zelfs prompt injection wordt begrensd. Een misleid model kan alleen tools aanroepen waarvoor de geauthenticeerde gebruiker al gemachtigd is.
De 2026 MCP-roadmap van Anthropic begint met enterprise-authenticatie en identity-provider-integratie. Het protocol beweegt deze kant op omdat het patroon werkt: tool-level RBAC tegen de corporate IdP verandert "het AI-beveiligingsprobleem" in een opgelost authenticatie-probleem. Wat het altijd al was.
Verbind MCP-servers via enterprise identity en MCP is niet verbonden met het platform. MCP is het platform.
Het werk dat ertoe doet
Wat de framework-industrie verkoopt is steigerwerk. Wat de uitkomsten daadwerkelijk verschuift is het specifieke, domein-gebonden werk van goede tool-descriptions schrijven: de juiste granulariteit kiezen, documenteren welke tool bij welke vraag past, query-strategieën toevoegen, foutmodes uit productie vastleggen en terug-voeren.
Niets daarvan kan worden uitbesteed aan een vendor, want niemand buiten jouw bedrijf weet wat jouw data betekent. Maar het is allemaal bereikbaar in een paar weken per domein, met één engineer en één domeinexpert. Dat is de deal waarvan ze je vertellen dat hij niet bestaat.
De vraag die "welk framework moet ik kiezen?" vervangt
Als je vandaag begint met MCP-werk, is de meest nuttige vraag niet "welk framework heb ik nodig?" Hij is "wat is de kleinste nuttige tool die ik kan schrijven voor die ene persoon wiens week morgen beter wordt als hij werkt?"
Bouw die. Kijk hoe ze hem gebruiken. Schrijf op wat ze probeerden dat niet werkte. Update de tool-description. Lever de volgende.
Drie maanden daarvan in een echt bedrijf produceert negen productie-servers en nul framework-afhankelijkheden. Dat is het verhaal: niet dat frameworks slecht zijn, maar dat ze voor de meeste mkb-bedrijven niet het eerste probleem zijn om op te lossen.
Het model is de agent. De IdP is de beveiligingsgrens. MCP is het platform. Bouw voor het platform, niet eromheen.