MCP in Productie: De Praktijkgids

Het meeste dat er in 2026 over MCP geschreven wordt valt in twee categorieën: marketing voor het product van een vendor, of tutorials voor een hackathon-demo. Dit is geen van beide.

Na drie maanden waarin ik bij één middelgroot engineering-bedrijf negen MCP-servers in productie heb gebracht, ontstond er een samenhangend framework. De stelling: voor het mkb (vijf tot twintig kernsystemen, bereikbare domeinexperts, geen Fortune-500-complexiteit) is MCP samen met je bestaande identity-laag het complete AI-platform. Geen RAG, geen agent-frameworks, geen AI-platform-vendors.

Deze gids loopt het hele framework door, van A tot Z. Elke sectie verwijst door naar een uitgebreide post over het onderwerp, en naar het practitioner report voor de volledige methode.

Waarom de meeste enterprise AI mislukt

Volgens MIT mislukt meer dan 80% van de enterprise-AI-projecten. De branche wijst naar datakwaliteit. Die diagnose klopt grotendeels niet.

In de praktijk is de data meestal prima. Het probleem zit in de 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 echte monteursnaam staat in de tijdregistraties van een ander systeem, en niemand heeft dat aan de AI verteld.

De meeste "AI-dataproblemen" zijn documentatieproblemen in een ander jasje. Repareer die 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 ladder met zes niveaus

Zodra je accepteert dat betekenis in de tool-description leeft, kun je MCP-servers gaan beoordelen op hoe serieus ze die laag aanpakken. Na 52 tools over negen API's heen ontstond er een ladder:

Niveau 1: API-Mapper (~70%). Eén tool per endpoint. Beschrijvingen van één zin. Het model verzint zijn queries en faalt.
Niveau 2: Functioneel (~20%). Tools netjes gegroepeerd, langere beschrijvingen, geen domeinkennis. Het plafond waar de meeste commerciële implementaties op mikken.
Niveau 3: Metadata-rijk (~8%). Knowledge graphs die naast de tool leven. De agent leest die side-channels zelden; ik heb twee van die lagen gebouwd en beide weer weggehaald.
Niveau 4: Zelflerend (<2%). Domeinkennis leeft binnen de tool-description, ontdekt door AI uit echte data, gevalideerd door experts. Klaar voor productie.
Niveau 5: Interactieve app (in opkomst). De server stuurt gerenderde UI terug.
Niveau 6: Veilige schrijf-app (frontier). De server schrijft terug, afgeschermd door de IdP, gestructureerd rond expliciete intentie van de gebruiker.

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 echte werk

97,1% van de MCP tool-descriptions, gemeten over 856 tools verspreid over 103 servers, bevat minstens één kritieke smell: onbenoemde beperkingen, ontbrekende richtlijnen, ondoorzichtige parameters. Dat is geen randverschijnsel. Dat is het gemiddelde.

Een tool-description is geen zin. Het is een operationele handleiding, opgebouwd uit blokken, en elk blok is toegevoegd omdat de agent er zonder faalde. Na 52 tools in productie kwam ik uit op 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 de praktijk gedragen ze zich totaal anders.

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

Introspective Context Engineering for MCP

Het lastigste bij het schrijven van goede tool-descriptions is dat de domeinkennis die ze vragen in de hoofden van je team zit, niet in enig document. Een domeinexpert vragen om 500 woorden operationele richtlijnen per tool te dicteren levert droge, onvolledige tekst op. Hem patronen laten reviewen die de AI heeft ontdekt levert precisie in een fractie van de tijd.

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

Examine: laat een AI op echte data los. Vraag het om patronen te ontdekken, verwarrende velden te markeren, hypothesen te formuleren.
Flag: de AI markeert elk patroon met een mate van zekerheid (zeker, waarschijnlijk, onzeker).
Validate: de domeinexpert beoordeelt. Bevestigt, corrigeert of verwerpt.
Encode: gevalideerde patronen worden in de tool-description en het schema verwerkt.
Iterate: gebruik in productie legt nieuwe gaten bloot; de cyclus herhaalt zich.

Dit draait de klassieke metadata-curatie om. In plaats van mensen alles te laten opschrijven (wat niet schaalt), stelt de AI de vragen en keurt de mens de antwoorden goed (wat wel schaalt). Het resultaat: gestructureerde domeinkennis op de enige plek waar de agent het betrouwbaar leest.

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

De volledige methode met de feedback-architectuur staat in het practitioner report (Engels).

De feedback-loop

Een goede MCP-server bouw je niet één keer. Hij groeit mee. Drie patronen duiken op in productie-telemetrie die geen enkele ontwerpsessie van tevoren ziet aankomen:

De agent roept dezelfde tool drie keer aan met steeds strakkere filters → de beschrijving zei niet welk filter eerst aan moet.
De agent verzint een parameter die niet bestaat → het schema liet ruimte voor twijfel 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.

Zonder instrumentatie zie je hier niets van. Wat wel werkt: elke tool accepteert een queryIntent-string (één zin van de agent over wat hij probeert te vinden) en logt die naast de parameters. De logs laten zien wat de agent dacht te doen, en dat legt het exacte metadata-gat bloot.

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

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

Waar de MCP-spec tekortschiet

Na 52 tools in productie werden zes gaten in de huidige spec te groot om te negeren. De belangrijkste drie:

Resources zijn het antwoord van de spec op referentiedocumentatie. Geen geteste client toont ze betrouwbaar. Ik heb twee Resource-lagen gebouwd en allebei weer weggehaald. Alles wat ertoe doet moet in de tool-description staan.
Enums zijn los gedefinieerd. Verschillende clients renderen ze verschillend, en sommige tonen de 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, en weinig daarvan overleeft een enterprise-audit.

Geen reden om MCP op te geven. Wel reden om servers te bouwen rond de delen van de spec die werken, en aan te dringen op wijzigingen waar dat niet zo is.

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 gecombineerd:

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

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

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

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

Zonder enterprise-budget

Enterprise AI wordt verkocht als iets dat alleen grote bedrijven kunnen betalen. Het pad dat dat prijskaartje rechtvaardigt (eigen chat-UI, prompt-platform, RAG-pijplijn, agent-framework, model-gateway, observability-stack) legt een kleiner bedrijf in één klap vast op een bouw-budget, een platform-team, een verouderend vastgepind model en een onvoorspelbare per-token-rekening.

Het alternatief is één structurele keuze: huur het oppervlak, bezit het domein. Sluit een abonnement af op de chat-client van een 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 gaat 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 opgewaardeerd, gratis.

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

Hoe je begint

Het recept dat werkte, negen keer toegepast:

Kies één domeinexpert die het te druk heeft. De boekhouder die telkens vragen krijgt over projectmarges. De wagenparkbeheerder die steeds gevraagd wordt waar de busjes zijn. De energiespecialist die elke week handmatig weerdata trekt. De persoon wiens week zichtbaar beter wordt als één specifieke vraag direct antwoord krijgt.
Kies één concrete vraag die die persoon elke week krijgt. Geen categorie. Eén echte vraag, met een bekend goed antwoord, die handmatig meer dan vijf minuten kost.
Bouw één MCP-tool die hem beantwoordt. Het maakt niet uit waar de data 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.
Hang hem aan je bestaande IdP zodat alleen die expert (en de mensen die hij expliciet machtigt) hem mag aanroepen.
Geef hem aan de expert. Kijk wat ze proberen. Log elke call. Ze proberen dingen die je niet had voorzien.
Update de tool-description op basis van wat je zag. Voeg WHEN NOT TO USE-blokken toe. Voeg voorbeelden toe. Scherp de QUERY STRATEGY aan. Lever de fix zo mogelijk dezelfde dag op.
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 meerdere domeinen levert een portfolio van werkende MCP-servers op en een team dat ze uit zichzelf gebruikt. Geen projectplan. Een gewoonte.

De sla-over-lijst, net zo belangrijk:

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

De volledige methode

Deze gids is het overzicht voor de praktijk. Het complete framework, met de Introspective Context Engineering for MCP-methode, het maturiteitsmodel met zes niveaus, het WriteIntent-patroon voor veilige writes, en de analyse van waar het MCP-ecosysteem heen beweegt, staat in het practitioner report (Engels).

Als je één tool oplevert die binnen een week door één collega uit zichzelf gebruikt wordt, ben je al voorbij de grens die 80% van de enterprise-AI-projecten nooit haalt. De rest is dat lusje herhalen totdat je bedrijf één MCP-vormige laag heeft in plaats van een berg integratie-projecten.

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

Verder lezen: lees het volledige practitioner report, The Missing Layer (Engels), of bekijk de werkende code in de mcp-metadata-demo server.