Wat is een MCP-server? Zo werken MCP en MCP UI in 2026

Op 1 april 2025 publiceerde Invariant Labs een tool met de naam add. Die nam twee getallen en gaf hun som terug. De beschrijving bevatte ook een blok gemarkeerd met IMPORTANT, onzichtbaar in de interface van de client, dat het model opdroeg ~/.cursor/mcp.json en ~/.ssh/id_rsa te lezen en beide bestanden via een extra parameter naar buiten te sturen. Het model gehoorzaamde. De gebruiker zag een optelsom.

Die demonstratie is de nuttigste introductie tot MCP-servers die ik ken, omdat ze beide helften tegelijk laat zien. Het protocol werkte precies zoals ontworpen: een AI-client ontdekte een tool, las de beschrijving en riep hem aan. Het vertrouwensmodel was het deel dat nog niemand had gebouwd.

Wat een MCP-server is

Een MCP-server is een programma dat tools, data en prompts beschikbaar stelt aan AI-applicaties via het Model Context Protocol (MCP). De officiële documentatie definieert MCP als “een open-source standaard om AI-applicaties te verbinden met externe systemen.” Een AI-client zoals Claude, ChatGPT, Visual Studio Code of Cursor maakt verbinding met de server, vraagt wat die aanbiedt en roept die mogelijkheden aan namens de gebruiker.

Anthropic kondigde MCP aan op 25 november 2024, met zes kant-en-klare servers: Google Drive, Slack, GitHub, Git, Postgres en Puppeteer. OpenAI nam het in maart 2025 over. Google DeepMind volgde in april. In december 2025 schonk Anthropic het protocol aan de Agentic AI Foundation, een fonds onder de Linux Foundation dat Anthropic, Block en OpenAI samen oprichtten.

Het probleem is vermenigvuldiging. Vóór MCP schreef elke AI-app die GitHub wilde bereiken een eigen connector. Elke leverancier bouwde op zijn beurt een verbinding per AI-app. Tien modellen en tien tools konden honderd integraties betekenen. MCP maakt daar twintig van: iedere client implementeert het protocol één keer en ieder systeem biedt één server aan.

Zie het als de zeecontainer van AI-integraties. Vóór de container laadde elke haven elke lading met de hand, met eigen kranen en een eigen ploeg. De container standaardiseerde de doos, zodat elk schip, elke kraan en elke vrachtwagen elke lading kon verplaatsen. Hij standaardiseerde niet wat er in de doos zat, en hij controleerde de inhoud nooit. MCP sluit dezelfde deal. Onthoud die tweede helft; ze komt terug bij de beveiliging.

Hoe een MCP-server werkt

De huidige specificatie, versie 2026-07-28, gebruikt JSON-RPC 2.0-berichten tussen drie rollen. De eigen omschrijving is drie regels lang: hosts zijn “LLM-applicaties die verbindingen starten”, clients zijn “connectors binnen de hostapplicatie”, en servers zijn “diensten die context en mogelijkheden leveren.”

Host, client, server

De host is de applicatie waarin je typt: Claude Desktop, een IDE, je eigen agent. Daarbinnen draait één client per serververbinding. De server zit aan de andere kant en praat met het echte systeem, of dat nu een Postgres-database is, de GitHub-API of een map op je schijf. De host beslist wat het model ziet en wat de gebruiker moet goedkeuren. De server beslist wat het onderliggende systeem doet.

1. Host Claude Desktop · een IDE · je eigen agent

   toont het model de tools, vraagt de gebruiker om toestemming

2. Client één per serververbinding

   spreekt JSON-RPC via stdio of Streamable HTTP

3. MCP-server tools · resources · prompts

   beschrijft wat hij aanbiedt en voert de aanroepen uit

4. Onderliggend systeem database · SaaS-API · lokale bestanden

   doet het werk

Tools, resources en prompts

Een server kan drie soorten dingen aanbieden:

• Tools zijn functies die het model kan uitvoeren: create_issue, query_orders, send_email. Elke tool heeft een naam, een beschrijving en een JSON Schema voor de invoer.
• Resources zijn context en data die de gebruiker of het model kan lezen: een bestand, een databaseschema, een record.
• Prompts zijn sjabloonberichten en workflows die de gebruiker kan kiezen, zoals “vat deze pull request samen”.

Tools krijgen de meeste aandacht omdat ze handelen. Daarom dragen ze ook het meeste risico.

Een toolaanroep, stap voor stap

De revisie van 2026-07-28 maakte MCP stateless. Er is geen initialize-handshake meer. Elk verzoek draagt zijn protocolversie en de mogelijkheden van de client mee in een _meta-veld, en servers moeten een server/discover-methode implementeren, zodat een client vooraf kan vragen wat ze ondersteunen. Eén toolaanroep verloopt nu zo:

1. Gebruiker vraagt: maak een ticket aan voor deze bug

2. Stap 1

   Ontdekken

   • De client kan server/discover aanroepen voor versies en mogelijkheden
3. Stap 2

   Tools opvragen

   • tools/list geeft namen, beschrijvingen en invoerschema’s terug
4. Stap 3

   Model kiest een tool

   • De host geeft de tooldefinities door aan het model
5. Stap 4

   Toestemming van de gebruiker

   • Volgens de spec moeten hosts expliciete toestemming vragen voordat ze een tool aanroepen
6. Stap 5

   Aanroep

   • tools/call met argumenten, protocolversie in _meta

7. Ontbreekt er invoer? De server geeft input_required terug, de client probeert opnieuw met de antwoorden

   Stap 6

   Resultaat

8. Het resultaat gaat als context terug naar het model

Stap 6 is nieuw in deze revisie. Een server die meer informatie nodig heeft, stuurt niet langer zelf een verzoek terug naar de client. Hij geeft een resultaat terug gemarkeerd met input_required, de client verzamelt het antwoord en probeert de oorspronkelijke aanroep opnieuw. De spec noemt dit het Multi Round-Trip Request-patroon.

Transports: stdio en Streamable HTTP

De spec definieert twee standaard-transports:

• stdio: de client start de server als subproces en wisselt JSON-RPC-berichten uit via standaardinvoer en -uitvoer, één bericht per regel. Zo draaien de meeste lokale servers, en dat betekent dat de server op jouw machine draait, met jouw rechten.
• Streamable HTTP: elk bericht is een HTTP POST naar één endpoint, en antwoorden komen terug als JSON-object of als eventstream die bij dat ene verzoek hoort. Zo draaien externe, gehoste servers.

Het oudere HTTP+SSE-transport is formeel verouderd. De revisie van 2026-07-28 schrapte ook sessies op protocolniveau en de Mcp-Session-Id-header. Een server die status over meerdere aanroepen nodig heeft, maakt nu zelf een handle aan en krijgt die terug als gewoon toolargument.

Autorisatie

Autorisatie is in MCP optioneel en geldt alleen voor HTTP. Bij stdio zegt de spec dat servers hun inloggegevens uit de omgeving moeten halen. Bij HTTP gedraagt een beschermde MCP-server zich als OAuth 2.1-resourceserver. Hij moet OAuth Protected Resource Metadata (RFC 9728) publiceren, zodat clients zijn autorisatieserver kunnen vinden. Clients moeten de exacte server noemen waarvoor een token bedoeld is (RFC 8707-resource-indicators). Servers moeten elk token weigeren dat niet voor hen is uitgegeven, en de beveiligingsrichtlijnen noemen “token passthrough”, het ongewijzigd doorsturen van het token van een client naar een achterliggende API, uitdrukkelijk verboden.

Die laatste regel weegt zwaarder dan hij lijkt. Een server die elk ontvangen token doorgeeft, wordt een proxy voor iedereen die er een heeft.

Wat MCP UI toevoegt: servers die een interface teruggeven

Tekstantwoorden werken niet meer zodra een gebruiker veertig rijen moet vergelijken, een formulier met twaalf velden moet aanpassen of een reeks wijzigingen een voor een moet goedkeuren. “MCP UI” is de naam waarop mensen zoeken naar de oplossing: een server geeft een interactieve interface terug die in de AI-client wordt weergegeven, naast het gesprek.

De status vraagt om precisie. Het idee begon met MCP-UI, een gemeenschapsproject. OpenAI bouwde een vergelijkbaar mechanisme in zijn Apps SDK. Het MCP-project stelde op 21 november 2025 samen met beide initiatieven een standaard voor. Op 26 januari 2026 verscheen MCP Apps als eerste officiële MCP-uitbreiding. De MCP-UI-pakketten implementeren nu die standaard en blijven een plek om toekomstige verbeteringen te onderzoeken.

MCP UI betekent vandaag dus MCP Apps. Het is officieel, en het is een extensie, geen kernprotocol. Extensies zijn optioneel: client en server moeten ze allebei ondersteunen, en de documentatie zegt onomwonden dat “ondersteuning per client verschilt.” De documentatie van MCP Apps noemt Claude, Claude Desktop, VS Code GitHub Copilot, Microsoft 365 Copilot, Goose, Postman, MCPJam en Archestra.AI als hosts met ondersteuning. Een server waarvan de tools UI teruggeven, moet nog steeds werken voor een client die alleen tekst toont.

Technisch hergebruikt het de eigen bouwstenen van MCP:

1. De beschrijving van een tool bevat een _meta.ui.resourceUri die naar een ui://-resource wijst.
2. De host haalt die resource op, een HTML-pagina met scripts, en kan hem vooraf laden voordat de tool wordt aangeroepen.
3. De host toont hem in een gesandboxt iframe dat de bovenliggende pagina, de cookies en de opslag niet kan lezen.
4. De app en de host praten via postMessage in een JSON-RPC-dialect van MCP. De app kan toolaanroepen aanvragen, en de host beslist welke hij toestaat.

De kosten zijn echt. Je levert nu een webfrontend binnen de applicatie van iemand anders, met een content security policy die je moet declareren, weergaveregels waar je geen controle over hebt en een tekstalternatief voor elke host die het negeert. De winst is dat goedkeuringswerk geen chattranscript meer is. De eigen lijst van goede toepassingen in de documentatie eindigt met “onkostendeclaraties goedkeuren, codewijzigingen beoordelen of issues triëren”, en dat is de eerlijke kern: MCP UI is het sterkst bij beslissingen, niet bij decoratie.

Een lezend Tajo-voorbeeld

De Alto-MCP-interface van Tajo bevat query_contacts. Deze tool zoekt contacten die in de verbonden werkruimte zijn opgeslagen. Zoek een bestaand contact op e-mailadres en controleer de teruggegeven ID, e-mailtoestemming en het tijdstip waarop het contact voor het laatst is waargenomen. De afzonderlijke tool get_contact_topic_status leest de onderwerpabonnementen van dat contact.

Deze aanroepen lezen werkruimtegegevens. Ze halen geen actuele kopie bij de leverancier op, starten geen synchronisatie en versturen geen bericht. Ze bewijzen evenmin dat alle connectoren actief zijn. Onderzoek ontbrekende of verouderde gegevens bij de bron. Een leeg resultaat bewijst niet dat de persoon in Brevo ontbreekt.

Gebruik de Tajo-MCP-documentatie om een ondersteunde client te verbinden en te bekijken welke tools je geautoriseerde werkruimte werkelijk aanbiedt. Een interactief paneel kan die controle vergemakkelijken als de host MCP Apps ondersteunt. Het tekstresultaat moet de uitkomst ook uitleggen.

Een toolaanroep is geen blijvende synchronisatie

Een terugkerende synchronisatie vereist ook een schema, stabiele recordidentiteiten, opgeslagen voortgang, regels voor nieuwe pogingen en een logboek van voltooide schrijfacties. Daarvoor is de uitvoerende applicatie verantwoordelijk. MCP standaardiseert tooltoegang; een tool in een lijst levert die bedrijfsregels niet vanzelf.

Na een time-out kun je een leesactie meestal herhalen. Een verzending of betaling kan al zijn uitgevoerd. Bewaar het uitvoeringslogboek en stel de uitkomst vast voordat je opnieuw probeert. Het vertrouwen van een model geeft geen toestemming voor de actie en maakt herhaling niet veilig.

De Brevo-API-handleiding beschrijft de doelschrijfactie voor een concreet contactpad. Lees reverse ETL om te bepalen wanneer berekende velden een eigen onderhouden synchronisatie rechtvaardigen.

De beveiligingsrekening komt met het protocol mee

Het bezwaar verdient het om volledig te worden uitgesproken: “MCP geeft een probabilistisch model een lijst functies die data kunnen verwijderen en e-mail kunnen versturen, en vertrouwt dan op tekst van vreemden om ze te beschrijven. Dat is geen integratiestandaard. Het is een supply-chain-aanval met een specificatie.” Het meeste daarvan klopt. De spec is het met het uitgangspunt eens. De beveiligingssectie zegt dat tools “willekeurige code-uitvoering vertegenwoordigen en met gepaste voorzichtigheid moeten worden behandeld”, dat toolbeschrijvingen “als onbetrouwbaar moeten worden beschouwd, tenzij ze van een vertrouwde server komen”, en dat MCP “deze beveiligingsprincipes niet op protocolniveau kan afdwingen.”

Dit is de stand tot nu toe:

• Tool poisoning (vergiftigde toolbeschrijvingen). De melding van Invariant Labs uit april 2025, de add-tool hierboven. Dezelfde post beschreef rug pulls, waarbij een server de beschrijving van een tool wijzigt nadat je die hebt goedgekeurd, en shadowing, waarbij één kwaadaardige server het gedrag van het model tegenover een vertrouwde server herschrijft.
• Gecompromitteerde lokale servers. In juli 2025 maakte JFrog CVE-2025-6514 bekend in mcp-remote, versies 0.0.5 tot en met 0.1.15, waarmee een kwaadaardige server opdrachten kon uitvoeren op de machine van de gebruiker. Dezelfde zomer trof CVE-2025-49596 Anthropics eigen MCP Inspector, die standaard zonder authenticatie werd geleverd.
• Opgeblazen scopes. De officiële best practices voor beveiliging benoemen het patroon: tokens die vooraf files:* of admin:* krijgen, omdat een server elke scope opsomde en de client ze allemaal aanvroeg.
• Officiële zorg. In mei 2026 zei de Amerikaanse National Security Agency dat de “snelle verspreiding van MCP de ontwikkeling van het beveiligingsmodel heeft ingehaald.”

Waar het bezwaar de mist ingaat, is de conclusie. De oplossing was nooit om te stoppen met modellen aan systemen koppelen. Teams deden dat al, met ruwe API-sleutels geplakt in prompts en scripts, zonder enige audittrail. De oplossing is een MCP-server te behandelen als elke andere afhankelijkheid met privileges:

• Installeer servers alleen uit bronnen die je buiten MCP ook met dezelfde inloggegevens zou vertrouwen.
• Kies liever externe servers met OAuth en smalle scopes dan lokale binaries met langlevende sleutels.
• Eis menselijke goedkeuring voor elke schrijfactie, en log wie wat heeft goedgekeurd.
• Zet serverversies vast, en beoordeel opnieuw zodra de beschrijving van een tool verandert.
• Bied tools aan die op de taak zijn toegesneden, geen volledige API. Een model kan geen delete-endpoint misbruiken dat nooit is aangeboden.

Het protocol standaardiseerde de doos. De lading inspecteren blijft jouw werk.

Een MCP-server bouwen of een bestaande gebruiken

Openbare directories zoals mcp.so verzamelen servers uit de community, en veel SaaS-leveranciers publiceren hun eigen server. Brevo levert bijvoorbeeld een MCP-server die ook in losse servers is opgesplitst, zodat een agent toegang kan krijgen tot contacten zonder campagnes. De keuze draait minder om moeite dan om de vraag wie de vorm van de tools hoort te bepalen.

Welke MCP-server moet je agent gebruiken?

1. De leverancier publiceert een server die de taak dekt

   Gebruik de server van de leverancier

   Hij volgt de API en de leverancier onderhoudt hem.

2. Eén systeem, maar je wilt minder of veiligere acties

   Gebruik hem, ingeperkt

   Geef minimale scopes en bied alleen de toolgroepen aan die de agent nodig heeft.

3. Interne data of een systeem zonder server

   Bouw een kleine server

   Een paar taakgerichte tools bovenop je eigen API, met je eigen authenticatie.

4. De taak beslaat twee of meer systemen

   Bouw of kies een beheerde laag

   Eén set tools, toestemmingsregels en audithistorie over al die systemen.

Een eenvoudige server bouwen is het makkelijke deel. Met een officiële SDK is een werkende stdio-server met één tool een middag werk. De kosten komen later: OAuth voor de HTTP-versie, verouderde onderdelen (de revisie van 2026-07-28 markeerde Roots, Sampling en Logging als verouderd, en ook Dynamic Client Registration), en het doorlopende werk van toolbeschrijvingen schrijven die een model correct leest. Een API verpakken met één tool per endpoint is de meest gemaakte fout. Elke toolbeschrijving is tekst die het model moet lezen en afwegen, dus een korte lijst taakgerichte tools wint van het volledige API-oppervlak.

MCP, API’s, integraties en iPaaS

MCP vervangt geen API’s. Bijna elke MCP-server is een wrapper rond een API. De API is nog steeds waar het werk gebeurt, met eigen rate limits, een eigen datamodel en eigen eigenaardigheden. MCP verandert wie hem kan aanroepen: een model, tijdens runtime, dat de aanroep kiest op basis van een beschrijving in plaats van een developer die hem vooraf hardcodeert.

Dat onderscheid trekt een scherpe lijn tegenover de twee andere dingen waarmee MCP verward wordt:

• Integraties en iPaaS (de belangrijkste platforms worden hier vergeleken) verplaatsen data volgens een schema of na een trigger, deterministisch, of er nu iemand in een chat zit of niet. Een nachtelijke synchronisatie van 40.000 bestellingen naar een CRM mag niet afhangen van een model dat besluit 40.000 toolaanroepen te doen.
• Reverse ETL duwt gemodelleerde data uit een datawarehouse terug naar operationele tools. Wat reverse ETL is en wanneer het past is een onderwerp op zich, en het is een pijplijn, geen gesprek.
• MCP is voor de momenten waarop een persoon of een agent op aanvraag iets moet vragen, inspecteren of uitvoeren in die systemen.

De fout gaat beide kanten op. Teams bouwen MCP-servers voor bulksynchronisatie en krijgen trage, dure pijplijnen die niet herhaalbaar zijn. Andere teams bouwen zorgvuldige integraties en geven hun AI-assistent dan een ruwe API-sleutel om ze te bevragen, en krijgen een onbeheerde achterdeur.

Bij een ondersteunde integratie moeten de blijvende taak en de tools om die te inspecteren een expliciete permissiegrens delen. Controleer de connector, toegestane acties en vastgelegde resultaten voor die workflow. De integratiedocumentatie onderscheidt instelinstructies van paden waarvoor nog productiebewijs ontbreekt. MCP kan afzonderlijke goedgekeurde tools aanbieden. Hun vermelding bewijst niet dat een terugkerende synchronisatie of alle vereiste controles actief zijn.

In 22 maanden ging MCP van zes referentieservers naar een project van de Linux Foundation dat Claude, ChatGPT, VS Code en Cursor allemaal spreken. Een model aan een systeem koppelen is nu het goedkope deel. Bepalen wat het daar mag doen, is het werk.