MCP in Productie: De Praktijkgids

Het meeste MCP-schrijven in 2026 valt in twee bakjes: marketing voor het product van een vendor, of tutorials voor een hackathon-demo. Dit is geen van beide.

Na het opleveren van negen productie MCP-servers bij één mid-sized engineering-bedrijf in drie maanden, kwam er een coherent framework naar boven. De these: voor mkb-bedrijven (vijf tot twintig kerndatabronnen, toegankelijke domeinexperts, geen Fortune-500-complexiteit) is MCP plus je bestaande identity-infrastructuur het hele AI-platform. Geen RAG. Geen agent-frameworks. Geen AI-platform-vendors.

Deze gids loopt het framework van begin tot eind door. Elke sectie linkt naar een uitgebreide post over het onderwerp, en naar het white paper voor de volledige methode.

Waarom de meeste enterprise AI faalt

MIT zet het enterprise-AI-faalpercentage boven 80%. De industrie geeft data-kwaliteit de schuld. Die diagnose klopt grotendeels niet.

In de praktijk is de data meestal prima. Wat kapot is, is betekenis: de AI weet niet wat je data betekent, hoe de systemen samenhangen, welke bron welke vraag beantwoordt. Het monteur-veld op de werkbon is leeg, maar de werkelijke monteursnaam staat in de tijdregistraties van een parallel systeem, en niemand heeft dat aan de AI verteld.

De meeste "AI data-problemen" zijn documentatie-problemen in een ander jasje. Repareer de documentatie op de enige plek waar het model die bij elke call betrouwbaar leest (de tool-description) en de data begint te werken.

Volledig argument met concrete voorbeelden: Je Data Is Prima. Je AI Begrijpt Het Alleen Niet..

De zes-niveau-maturiteitsladder

Zodra je accepteert dat betekenis in tool-descriptions leeft, kun je MCP-servers gradueren op hoe serieus ze die laag behandelen. Na 52 tools over negen API's heen, kwam er een ladder naar boven:

• Niveau 1: API-Mapper (~70%). Eén tool per endpoint. Beschrijvingen van één zin. Het model verzint en faalt.
• Niveau 2: Functioneel (~20%). Tools netjes gegroepeerd, langere beschrijvingen, geen domeinkennis. Het plafond dat de meeste commerciële implementaties nastreven.
• Niveau 3: Metadata-Rijk (~8%). Knowledge graphs die naast de tool leven. De agent leest side-channels zelden; ik heb twee van deze lagen gebouwd en beide weer verwijderd.
• Niveau 4: Zelflerend (<2%). Domeinkennis leeft binnen de tool-description, ontdekt door AI uit echte data, gevalideerd door experts. Productie-klaar.
• Niveau 5: Interactieve App (opkomend). De server retourneert gerenderde UI.
• Niveau 6: Veilige Schrijf-App (frontier). De server schrijft terug, afgeschermd door IdP, gestructureerd rond expliciete user intent.

De meeste publieke servers zitten tussen 1 en 2. MCP is niet dood; de meeste servers zijn gewoon leeg.

Volledige uiteenzetting: De Zes Niveaus van MCP-Servers.

Tool-descriptions zijn het werk

97,1% van de MCP tool-descriptions, over 856 tools verspreid over 103 servers, bevat minstens één kritieke smell: onbenoemde beperkingen, ontbrekende gebruiksrichtlijnen, ondoorzichtige parameters. Dat is geen rand-fenomeen. Dat is de basislijn.

Een tool-description is geen zin. Het is een operationele handleiding, gestructureerd in blokken, elk toegevoegd omdat de agent er zonder faalde. Na 52 productie-tools convergeerde het patroon naar acht: RETURNS, WHEN TO USE, WHEN NOT TO USE, QUERY STRATEGY, INTERPRETATION, EXAMPLES, CROSS-REFERENCES, FAILURE MODES.

Dezelfde data achter een Niveau-1- en een Niveau-4-tool. In productie-gedrag zijn het totaal andere producten.

Het acht-blok-patroon met voorbeelden: 97% van de MCP Tool-Descriptions Is Kapot.

Introspective Context Engineering

Het moeilijkste aan goede tool-descriptions schrijven is dat de domeinkennis die ze vereisen in de hoofden van je team leeft, niet in enig document. Een domeinexpert vragen om 500 woorden operationele richtlijnen per tool te dicteren levert droge, onvolledige tekst op. Hem vragen om AI-ontdekte patronen te reviewen levert precisie in een fractie van de tijd.

Dat inzicht werd een vijf-fasen-patroon dat ik Introspective Context Engineering (ICE) noem:

1. Examine: richt een AI op echte data. Vraag hem patronen te ontdekken, verwarrende velden te markeren, hypothesen te genereren.
2. Flag: de AI markeert elk patroon met een confidence-niveau (zeker, waarschijnlijk, onzeker).
3. Validate: de domeinexpert reviewt. Bevestigt, corrigeert of verwerpt.
4. Encode: gevalideerde patronen worden in de tool-description en het schema geschreven.
5. Iterate: productie-gebruik legt nieuwe gaten bloot; de cyclus herhaalt.

Dit keert de traditionele metadata-curatie-pijplijn om. In plaats van mensen alles te laten opschrijven (wat niet schaalt), stelt de AI vragen en keurt de mens antwoorden goed (wat wel schaalt). De output is gestructureerde domeinkennis op de enige plek waar de agent het betrouwbaar leest.

ICE is wat Niveau 4 in dagen in plaats van kwartalen bereikbaar maakt. Het is ook waarom het patroon werkt voor mkb-bedrijven en hapert op Fortune-500-schaal: het vereist een domeinexpert die een middag met je kan zitten, geen 40-koppige governance-commissie.

De volledige vijf-fasen-methode met de feedback-architectuur: white paper (Engels).

De feedback-loop

Een goede MCP-server bouw je niet één keer. Hij evolueert. Drie patronen duiken op in productie-telemetrie die geen ontwerp-sessie voorziet:

• De agent roept dezelfde tool drie keer aan met aanscherpende filters → de beschrijving zei niet welk filter eerst te proberen.
• De agent verzint een parameter die niet bestaat → het schema liet ambiguïteit over wat beschikbaar is.
• De agent gebruikt een tool voor een vraag die bij een andere tool hoort → beide WHEN TO USE-blokken moeten scherper.

Elk is onzichtbaar zonder instrumentatie. Het patroon dat werkt: elke tool accepteert een queryIntent-string (één zin van de agent die beschrijft wat hij probeert te vinden) en logt die naast de parameters. De logs onthullen wat de agent dacht te doen, wat het metadata-gat precies blootlegt.

Fixes zijn klein. Minuten per fix, niet weken per ontwerp-cyclus.

Het volledige patroon met het queryIntent-ontwerp: Je MCP-Server Zou Elke Week Slimmer Moeten Worden.

Wat de MCP-spec verkeerd doet

Na 52 tools in productie werden zes gaten in de huidige MCP-spec moeilijk te negeren. De headline-gaten:

• Resources zijn het antwoord van de spec op referentiedocumentatie. Geen geteste client toont ze betrouwbaar. Ik heb twee Resource-lagen gebouwd en beide verwijderd. Alles moet in de tool-description leven.
• Enums zijn los. Verschillende clients renderen ze verschillend; sommige tonen toegestane waarden helemaal niet aan het model. De agent verzint waarden en de tool wijst ze af.
• Geen standaard voor tool-level RBAC. Elk team rolt zijn eigen auth-patroon; weinig overleven een enterprise-audit.

Geen redenen om MCP op te geven. Redenen om servers te bouwen rond de delen van de spec die werken en aandringen op wijzigingen waar ze dat niet doen.

Volledige lijst: Zes Dingen Die de MCP-Spec Moet Fixen.

MCP plus identity is het platform

Dit is de herformulering die de meeste "heb ik een AI-platform nodig?"-gesprekken missen. Het platform is geen product dat je koopt. Het zijn twee stukken die je al hebt, anders gecomponeerd:

1. Een frontier-model dat MCP spreekt (Claude, GPT, Gemini, het protocol is hetzelfde).
2. De corporate identity-laag waar het bedrijf al voor betaalt (Entra, Okta, Google Cloud Identity).

Verbind MCP-servers via enterprise identity en het AI-platform is gebouwd. Tools authenticeren tegen de bestaande IdP, scopen toegang per rol, loggen elke call naar de audit trail die elk ander corporate systeem gebruikt. Een monteur ziet alleen zijn eigen werkbonnen. Een controller ziet geaggregeerde financiële cijfers, geen ruwe loonadministratie. Elke actie is toe te wijzen aan een named identity.

Dat is het hele enterprise-AI-beveiligingsmodel. Geen prompt-firewall-vendor. Geen AI-governance-platform. Geen model-gateway. Alleen access control dat het bedrijf al draait, afgedwongen op de MCP-tool-grens. De 2026-roadmap van Anthropic begint met enterprise-authenticatie. Het patroon werkt.

Volledig argument met de gebruik/sla-over-tabel: MCP Is Het AI-Platform.

Zonder een enterprise-budget

Enterprise AI wordt verkocht als iets dat alleen grote bedrijven kunnen betalen. Het pad dat dat prijskaartje rechtvaardigt (custom chat-UI, prompt-platform, RAG-pijplijn, agent-framework, model-gateway, observability-stack) verplicht een kleiner bedrijf tegelijk tot een bouw-budget, een platform-team, een verouderd vastgepind model, en een onvoorspelbare per-token-rekening.

Het alternatief is één structurele beslissing: huur het oppervlak, bezit het domein. Abonneer je op de chat-client van de vendor voor €19/seat/maand. Verbind je bestaande IdP. Steek je engineering-uren in MCP-servers voor de systemen die geen enkele vendor ooit voor je zal koppelen. Geen frontend om te onderhouden, geen platform-team om in te richten, geen orkestratie-platform om te kopen. Het model wordt op de klok van de vendor geüpgraded, gratis.

De volledige architectuur met de huur/bezit-uitsplitsing en het framework-absorptie-argument: Enterprise AI Zonder Enterprise Budget.

Hoe te beginnen

Het recept dat werkte, negen keer toegepast:

1. Kies één domeinexpert die te veel te doen heeft. De boekhouder die telkens marge-vragen krijgt. De wagenparkbeheerder die telkens gevraagd wordt waar de busjes zijn. De energiespecialist die telkens handmatig weerdata trekt. De persoon wiens week zichtbaar beter zou worden als een specifieke vraag direct beantwoord werd.
2. Kies één specifieke vraag die die persoon elke week krijgt. Geen categorie. Eén echte vraag, met een bekend correct antwoord, die handmatig meer dan vijf minuten kost.
3. Bouw één MCP-tool die hem beantwoordt. Wikkel om welke toegang de data ook achter zit (REST, GraphQL, SQL, file). Schrijf de description alsof je de data uitlegt aan een scherpe nieuwe collega die dit domein nog nooit heeft gezien.
4. Bedraad hem via je bestaande IdP zodat alleen die expert (en mensen die hij expliciet machtigt) hem mag aanroepen.
5. Geef hem aan de expert. Kijk wat ze proberen. Log elke call. Ze proberen dingen die je niet voorzag.
6. Update de tool-description om te fixen wat je zag. Voeg WHEN NOT TO USE-blokken toe. Voeg voorbeelden toe. Verscherp de QUERY STRATEGY. Lever de fix zo mogelijk dezelfde dag.
7. Kies de volgende vraag. Bouw de volgende tool. Voeg hem toe aan dezelfde server als het hetzelfde domein is, een nieuwe server als het een nieuw domein is.

Drie maanden daarvan, over domeinen toegepast, produceert een portfolio van werkende MCP-servers en een team dat ze ongevraagd gebruikt. Geen projectplan. Een praktijk.

De sla-over-lijst, even belangrijk:

• Bouw niet eerst een framework.
• Bouw niet eerst een registry, een router of een "MCP-platform."
• Doe geen "AI-strategie" voordat je één nuttige tool hebt opgeleverd.
• Vraag geen toestemming. Domeinexperts zullen je danken; commissies vertragen je.

De volledige methode

Deze gids is het praktijk-overzicht. Het volledige framework met de Introspective Context Engineering-methode, het zes-niveau-maturiteitsmodel, het WriteIntent-patroon voor veilige writes, en de analyse van waar het MCP-ecosysteem heen gaat, is het white paper (Engels).

Als je één tool oplevert die één collega binnen een week ongevraagd gebruikt, ben je al voorbij de lijn die 80% van enterprise-AI-projecten nooit passeert. De rest is die loop herhalen totdat je bedrijf één MCP-vormige laag heeft in plaats van veel integratie-projecten.

Het model is de agent. De IdP is de beveiligingsgrens. MCP is het platform. Bouw voor het platform, niet eromheen.