Wat is een MCP Client? Hoe AI Agents verbinding maken met Tools

Het Model Context Protocol (MCP) wordt vaak omschreven als "USB-C voor AI," wat pakkend is en vrijwel nutteloos wanneer je daadwerkelijk een agent aan een database koppelt. De poortmetafoor verbergt het onderdeel dat het werk doet: het element aan de kabel dat het protocol spreekt. In MCP is dat element de client.

Als je AI-agents bouwt of beheert, is de client het onderdeel dat je om 2 uur 's nachts zit te debuggen wanneer een tool-call blijft hangen, wanneer een OAuth-token halverwege een sessie verloopt, of wanneer een server een tool aankondigt die je host nooit aan het model toont. Precies begrijpen wat de client doet, en wat hij niet doet, is het verschil tussen MCP behandelen als magie en het beheren als infrastructuur.

Dit artikel definieert de MCP client nauwkeurig: de rol binnen de drie-eenheid host/client/server, de levenscyclus van de verbinding stap voor stap, hoe clients authenticeren, waar clients daadwerkelijk draaien en waarom je op serieuze schaal een gateway tussen je clients en je servers plaatst.

Wil je één beheerd eindpunt voor elke MCP client in je organisatie in plaats van verspreide configuraties? Boek een demo.

De drie-eenheid host / client / server

MCP heeft drie rollen, en het verwarren ervan is de meest voorkomende bron van onduidelijkheid.

Een host is de AI-applicatie waarmee de gebruiker communiceert. Het heeft het beheer over het taalmodel (of de verbinding daarmee), het gesprek en de beslissing over welke tools aan het model worden blootgesteld en wanneer. Claude Desktop is een host. Cursor is een host. Een op maat gemaakte agent die je hebt geschreven met een SDK is een host.

Een client is een protocolconnector die door de host wordt geïnstantieerd. Zijn enige taak is het onderhouden van een verbinding met één server en het vertalen tussen de interne wereld van de host en het MCP-netwerkprotocol. De relatie is één-op-één: één client, één server. Een host die verbinding maakt met vijf servers, draait vijf clients. Elke client behoudt zijn eigen sessiestatus, zijn eigen set capabilities en zijn eigen inloggegevens.

Een server stelt capabilities, tools (functies die het model kan aangroepen), resources (leesbare gegevens zoals bestanden of rijen) en prompts (herbruikbare sjablonen) beschikbaar via het protocol. Een GitHub MCP server stelt create_issue en list_pull_requests beschikbaar. Een Postgres-server stelt een query-tool en tabel-resources beschikbaar.

De verdeling is belangrijk omdat verantwoordelijkheden elkaar niet overlappen. De host bepaalt het beleid ("mag het model delete_repo aanroepen?"). De client dwingt het protocol af ("is deze server geïnitialiseerd? is de capability aangekondigd?"). De server voert het werk uit en geeft een resultaat terug. Wanneer er iets misgaat, los je het op in de laag die er eigenaar van is. Een tool die nooit aan het model verschijnt, is meestal een host-probleem. Een tool die wel verschijnt maar een fout geeft bij het aanroepen, is meestal een client- of server-probleem.

Waarom één client per server

De één-op-één-regel is niet toevallig. Elke MCP-verbinding is een stateful sessie met onderhandelde capabilities. Server A ondersteunt mogelijk resource-abonnementen; Server B mogelijk niet. Server A authenticeert met een GitHub OAuth-token; Server B gebruikt inloggegevens voor een database. Door elke verbinding zijn eigen client te geven, blijft die status geïsoleerd, zodat een capability of een verlopen token op de ene verbinding een andere niet kan aantasten. De host wordt de multiplexer: hij verdeelt een enkel gebruikersverzoek over de clients die nodig zijn, verzamelt de resultaten en geeft ze terug aan het model.

Waarvoor de client verantwoordelijk is

Strip de metaforen weg en een conforme MCP client doet vijf concrete dingen.

Transport. Het zet de verbinding op en onderhoudt deze. MCP definieert twee standaard transportmethoden: stdio, waarbij de client de server start als een subprocess en communiceert via standard input/output, en Streamable HTTP, waarbij de client HTTP-verzoeken maakt naar een server-URL en een stroom van server-sent events kan ontvangen op de respons. Lokale tools (een bestandssysteem-server op je laptop) gebruiken doorgaans stdio. Remote tools (een gehoste service) gebruiken HTTP.

Message framing. Elk MCP-bericht is JSON-RPC 2.0. De client bouwt verzoekobjecten met een id, een method en params, koppelt antwoorden terug aan hun verzoeken via id en stuurt door de server geïnitieerde notificaties door. Als je wel eens naar ruw MCP-verkeer hebt gekeken, zie je dat het gewoon een stroom van JSON-RPC-enveloppen is.

Capability-onderhandeling. Bij het verbinden stuurt de client initialize met de protocolversie die hij spreekt en de capabilities die hij ondersteunt (bijvoorbeeld of hij sampling-verzoeken of elicitation kan verwerken). De server reageert met die van zichzelf. Vanaf die handshake weten beide kanten wat is toegestaan. Een client die probeert een capability te gebruiken die de server nooit heeft aangekondigd, bevat een bug.

Aanroepen (Invocation). Wanneer de host beslist dat het model een tool moet aanroepen, stuurt de client tools/call met de toolnaam en argumenten, wacht op het resultaat en geeft dit terug. Het doet hetzelfde voor resources/read en prompts/get.

Levenscyclus en opschonen. De client beheert de sessie van handshake tot afsluiting, inclusief het vernieuwen van tokens, opnieuw verbinden en het netjes verbreken van de verbinding wanneer de host deze sluit.

Merk op wat er niet in die lijst staat: beslissen of een tool-call veilig is, geheimen uit een resultaat verwijderen of voorkomen dat een doorgedraaide agent dezelfde tool 400 keer aanroept. Dat zijn zaken voor de host en governance. Het basisprotocol levert de leidingen, niet het beleid. Dat gat is precies waar enterprise-controles, die later worden besproken, moeten plaatsvinden.

De levenscyclus van de verbinding, stap voor stap

Een clientverbinding doorloopt een vaste reeks. Als je deze begrijpt, verander je de meeste MCP-storingen in een snelle "welke stap is mislukt?"-vraag.

1. Ontdekken (Discover). De client heeft een server nodig om mee te verbinden. Voor een lokale stdio-server is "discovery" een configuratie-item: een commando en argumenten om te starten. Voor een remote server is het een URL. In grotere omgevingen is discovery dynamisch: de client vraagt aan een registry of een gateway welke servers er bestaan en wat hun eindpunten zijn, in plaats van ze hardcoded in te voeren.

2. Authenticeren. Voor remote HTTP-servers moet de client bewijzen wie hij is voordat de server wil communiceren. Het autorisatiemodel van MCP is OAuth 2.1. De client ontdekt de autorisatieserver via protected-resource metadata (RFC 9728), registreert zichzelf optioneel dynamisch (RFC 7591), voert de authorization-code flow uit met PKCE (RFC 7636) en voegt het resulterende bearer-token toe aan elk verzoek. Lokale stdio-servers erven meestal het vertrouwen van de procesgrens en slaan dit over.

3. Initialiseren. De client stuurt het initialize-verzoek: zijn protocolversie, client-info en capabilities. De server reageert met zijn protocolversie, server-info en capabilities. Als de versies niet compatibel zijn, mislukt de verbinding hier meteen netjes, wat veel beter is dan drie tool-calls later mislukken. De client stuurt vervolgens een initialized-notificatie om te bevestigen dat de sessie actief is.

4. Capabilities tonen. De client roept tools/list aan, en indien nodig resources/list en prompts/list. De server geeft de naam, beschrijving en JSON Schema voor de invoer van elke tool terug. Dit is de catalogus die de host aan het model zal tonen. Servers kunnen later ook een listChanged-notificatie sturen als hun set van tools verandert, en een goed werkende client vraagt de lijst als reactie opnieuw op.

5. Aanroepen. De host kiest een tool (meestal omdat het model darum heeft gevraagd) en de client stuurt tools/call met gevalideerde argumenten. Een langdurige aanroep kan tussentijdse output streamen. De client koppelt de respons aan het verzoek via id.

6. Het resultaat verwerken. De client geeft het tool-resultaat terug aan de host, die het formatteert voor het model. MCP-resultaten bevatten een vlag die onderscheid maakt tussen een fout op tool-niveau (de tool is uitgevoerd en mislukt, bijv. "repository niet gevonden") en een fout op protocol-niveau (de aanroep zelf was onjuist geformatteerd). Het hetzelfde behandelen van die twee is een veelvoorkomende client-bug: "niet gevonden" is informatie voor het model, terwijl een protocolfout iets is wat je code moet afhandelen.

7. Afsluiten. Wanneer de host klaar is, sluit de client het transport: het beëindigen van het subprocess voor stdio, of het beëindigen van de HTTP-sessie voor remote.

Een minimale flow, concreet gemaakt

Stel je voor dat een coding agent de opdracht krijgt om "een issue met de titel 'Flaky CI' te openen in de api-repo." De reeks binnen de host is:

1. De client heeft al een geïnitialiseerde sessie met de GitHub MCP server, met een geldig OAuth-token.
2. De host heeft de toolcatalogus van tools/list; deze bevat create_issue met een schema dat owner, repo en title vereist.
3. Het model genereert een tool-call: create_issue({owner: "acme", repo: "api", title: "Flaky CI"}).
4. De client stuurt tools/call, de server maakt de issue aan en geeft {issue_number: 412, url: "..."} terug als een resultaat zonder fouten.
5. De client geeft dat terug; de host voert het in bij het model, dat antwoordt met "Issue #412 geopend."

Elk van die stappen is een plek waar iets mis kan gaan: een verlopen token (stap 1), een schema-mismatch die het model verkeerd heeft ingeschat (stap 3), een permissiefout aan de serverzijde die een tool-fout retourneert (stap 4). Kennis van de levenscyclus geeft aan waar je moet zoeken.

Hoe MCP clients authenticeren

Vroege MCP-verbindingen waren meestal lokale stdio-servers, waarbij authenticatie impliciet was. Remote servers veranderden dat, en het protocol is gestandaardiseerd op OAuth 2.1 in plaats van iets nieuws te bedenken.

Concreet doet een remote client het volgende:

• Leest protected-resource metadata (RFC 9728) van de server om te leren welke autorisatieserver deze beveiligt.
• Voert optioneel dynamic client registration (RFC 7591) uit, zodat hij geen vooraf ingestelde client-ID nodig heeft voor elke server die hij kan tegenkomen.
• Voert de authorization-code grant met PKCE (RFC 7636) uit, wat de uitwisseling beschermt, zelfs voor publieke clients die geen geheim kunnen bewaren.
• Voegt het uitgegeven bearer token toe aan elk verzoek en vernieuwt dit voor de vervaldatum.

De revisie van de specificatie op 2026-07-28 zette een duidelijke koers voort: richting stateless Streamable HTTP, waarbij een server een langdurige sessie niet aan een enkel proces hoeft te koppelen, en richting expliciete serveridentiteit via Mcp-Name-headers, zodat clients en tussenpersonen ondubbelzinnig naar een specifieke server kunnen verwijzen en routeren. Stateless transport is operationeel belangrijk omdat het servers in staat stelt horizontaal te schalen achter een load balancer. Als je een diepere uitleg wilt over token-flows, audience binding en foutmodi, bekijk dan onze gids over MCP authenticatie.

De praktische les: een client is maar zo veilig als zijn tokenafhandeling. Een client die bearer-tokens logt, de token-audience niet valideert of niet netjes vernieuwt, zal inloggegevens lekken of sessies onderbreken. Dit zijn verantwoordelijkheden van de client, en ze zijn lastig in hun eenheid goed te krijgen, nog een reden waarom gecentraliseerde afhandeling wint op schaal.

Waar MCP clients draaien: echte voorbeelden

"MCP client" klinkt abstract totdat je je realiseert dat je er waarschijnlijk al meerdere hebt gebruikt. Hier zijn de bekende voorbeelden en wat ze precies zijn.

De belangrijke nuance in die tabel: in elk geval is de client een onderdeel op bibliotheekniveau binnen het product. Claude Desktop is de host; het onderdeel dat daadwerkelijk JSON-RPC spreekt met de GitHub-server is een client-object dat door de host is aangemaakt. Wanneer je een op maat gemaakte agent schrijft met een MCP SDK, instantieer je dat client-object zelf en roep je connect(), list_tools() en call_tool() rechtstreeks aan.

Dat verklaart ook waarom dezelfde server zich op verschillende hosts net iets anders gedraagt. De server is identiek; de clients verschillen in hoe agressief ze tools opnieuw opvragen, hoe ze tool-fouten tonen aan het model en hoe ze auth afhandelen. "Het werkt wel in Claude Desktop maar niet in mijn agent" is bijna altijd een verschil in clientgedrag, niet in de server.

Ontdek hoe TrueFoundry auth, discovery en audit centraliseert voor elke agent en MCP client. Boek een demo.

Waarom een gateway tussen clients en servers staat op schaal

Verbind één client met één server en MCP is eenvoudig. Maak het nu realistisch: 200 ontwikkelaars, 30 interne MCP servers, elke host die probeert zijn eigen OAuth-tokens te beheren, elke server bereikbaar op zijn eigen URL, en een beveiligingsteam dat wil weten wie welke tool heeft aangeroepen.

Het model met directe verbindingen loopt snel vast:

• Wildgroei aan inloggegevens. Elke client bevat inloggegevens voor elke server. Het roteren van een geheim betekent het aanpassen van elke clientconfiguratie.
• Geen centrale discovery. Elke host voert server-URL's hardcoded in. Een server toevoegen of verplaatsen betekent het opnieuw onboarden van elke client.
• Geen governance. Het basisprotocol kent geen concept van "team X mag de database-server gebruiken maar niet de betalingsserver," geen gedeelde rate-limiting, geen audit-trail over servers heen.
• Inconsistente auth. Elke client implementeert OAuth net even anders; sommigen doen het slecht.

De oplossing is hetzelfde patroon dat de vergelijkbare chaos voor LLM API's heeft opgelost: plaats een gateway in het midden. Een MCP gateway geeft elke client één enkel eindpunt. De client authenticeert één keer bij de gateway; de gateway beheert en roteert de inloggegevens voor de achterliggende servers. Discovery wordt dynamisch: de client vraagt aan de MCP registry van de gateway wat er bestaat, in plaats van een statische lijst mee te dragen. En omdat elke aanroep via één plek loopt, krijg je governance, toegangsbeheer, rate limits en audit-mogelijkheden die het protocol zelf niet biedt.

Architectonisch weerspiegelt dit een LLM proxy: één logische voordeur, vele backends erachter, beleid dat in het midden wordt afgedwongen. De taak van de client wordt eenvoudiger, niet moeilijker: hij verbindt met één bekend eindpunt met één inloggegeven en laat de gateway de verdeling afhandelen.

Voor Gereguleerde omgevingen, waar de tools interne systemen aanroepen met gevoelige gegevens, is dit niet optioneel. Je hebt enterprise MCP governance nodig: toegangsbeheer per team over welke servers en tools bereikbaar zijn, volledige audit van elke tool-aanroep en de mogelijkheid om toegang centraal in te trekken. De MCP gateway en registry van TrueFoundry bieden precies dit: clients krijgen één eindpunt, authenticatie en RBAC worden centraal afgedwongen, elke tool-call is observeerbaar en getagd, en server-discovery verloopt via een beheerde registry in plaats van verspreide configuratiebestanden. Als je opties vergelijkt, behandelt ons overzicht van de beste MCP gateways de afwegingen, en behandelt MCP server hosting het draaien van de servers zelf.

Waar teams de mist in gaan

De host behandelen als de client. Teams zeggen "Cursor is mijn MCP client." Cursor is de host; het bevat clients. Het onderscheid is van belang zodra je gaat debuggen: een tool die het model nooit bereikt, is een beslissing aan de host-zijde, terwijl een tool die een fout geeft bij het aanroepen een client- of serverprobleem is. Het verwarren van de twee zorgt ervoor dat je in de verkeerde laag zoekt.

Deinitializehandshake negeren. Ontwikkelaars die custom clients schrijven, vuren soms een tools/call af voordat de capability-onderhandeling is voltooid, of gaan uit van een capability die de server nooit heeft aangekondigd. Het resultaat is een reeks wisselvallige, verwarrende storingen. De handshake is geen formaliteit; het is het contract. Respecteer het, anders kun je onvoorspelbaar gedrag verwachten.

Tool-fouten verwarren met protocolfouten. Een MCP-resultaat geeft aan of de tool zelf is mislukt (een 404 die het model moet zien en verwerken) versus een onjuist geformatteerde aanroep (een probleem in jouw code). Clients die deze samenvouwen, verbergen nuttige signalen voor het model of crashen bij herstelbare situaties.

Server-URL's en inloggegevens hardcoded invoeren in elke client. Het werkt voor drie servers, maar loopt vast bij dertig. Statische configuratie betekent dat elke rotatie en elke verplaatsing een verandering voor de hele omgeving is. Dynamische discovery via een registry is het enige dat schaalt.

Elke client zijn eigen OAuth laten afhandelen. OAuth 2.1 met PKCE en token-vernieuwing is eenvoudig subtiel verkeerd te implementeren: gelekte tokens in logs, ontbrekende audience-validatie, mislukte vernieuwing. Door auth te centraliseren bij een gateway implementeer je het één keer, correct, in plaats van N keer met N bugs.

Conclusie

De MCP client is het onopvallende onderdeel dat agentic toolgebruik laat werken: het onderhoudt de verbinding, onderhandelt over capabilities, authenticeert en verwerkt elke tool-call via JSON-RPC. Zorg dat je het mentale model scherp hebt — de host is eigenaar van het beleid, de client van de verbinding, de server voert het werk uit — en MCP stopt met magie zijn en wordt iets dat je kunt beheren en debuggen.

Bij één client en één server is het directe model prima. Op enterprise-schaal, met tientallen servers en honderden gebruikers, koppel je clients niet meer rechtstreeks aan servers en plaats je een gateway in het midden: één eindpunt, gecentraliseerde auth en discovery, en governance over elke tool-call. Dat is de architectuur die een groeiende vloot van agents zowel nuttig als beheersbaar houdt.

Geef elke MCP client één veilige gateway om mee te verbinden. Boek een demo.