MCP-versiestand: doorlopende tracker

Het Model Context Protocol (MCP) heeft zich in sneltreinvaart ontwikkeld van een experimenteel initiatief van Anthropic tot de de facto standaard voor de communicatie tussen AI-modellen, orchestratie-engines en externe gegevensbronnen. Waar ontwikkelaars voorheen voor elke API, database of lokale CLI-tool een maatwerk wrapper moesten schrijven, biedt MCP een uniform JSON-RPC 2.0 protocol over verschillende transportlagen. Dit document dient als een doorlopende tracker waarin we de evolutie van de specificatie, de volwassenheid van officiële en community SDK's, en de opkomende beveilings- en architectuurpatronen nauwkeurig bijhouden.

1. Specificatielandschap: Van v1.0 tot de huidige stand

De core-specificatie van MCP definieert de interactie tussen een client (zoals een AI-desktoptoepassing, IDE of agentic runtime) en een server (die gereedschappen, bestanden of contextuele data levert). Sinds de initiële release is het protocol gestructureerd rond drie hoofdcategorieën van vaardigheden: prompts (voorgedefinieerde sjablonen), resources (passieve data zoals bestandsinhoud of database-records) en tools (actieve functies die door het model aangeroepen kunnen worden).

In de huidige evolutie van de specificatie ligt de nadruk op robuuste onderhandeling van mogelijkheden (capability negotiation) tijdens de handdrukfase. Client en server wisselen bij het opstarten een initialize request en response uit, waarin expliciet wordt vastgelegd welke protocolkenmerken ondersteund worden. Voor een historisch overzicht van de initiële adoptie en de eerste vlaag van community-servers kun je de uitgebreide analyse over MCP en agent-tooling van juli 2026 raadplegen, waarin de fundamentele verschuiving naar gestandaardiseerde interfaces uitgebreid wordt toegelicht.

De tabel hieronder geeft het overzicht van de kernfunctionaliteiten en hun huidige ondersteuningsstatus in de specificatie:

2. Transportlagen: STDIO versus SSE en Stream Multiplexing

Het Model Context Protocol is bewust ontworpen als een transport-agnostisch protocol. De berichtenstructuur leunt op JSON-RPC 2.0, maar de manier waarop deze berichten fysiek verzonden worden varieert afhankelijk van het deployment-scenario. Er zijn momenteel twee primaire transportmechanismen gedefinieerd, elk met specifieke kenmerken, voordelen en operationele afwegingen.

Standard Input/Output (STDIO)

Het STDIO-transport is de meest directe en veilige methode voor lokale agent-opstellingen. De client start het MCP-serverproces op als een onderliggend proces (child process) en communiceert via de standaard input- en outputstreams. Berichten worden gescheiden door regeleinden (newline-delimited JSON-RPC).

• Voordelen: Geen netwerkpoorten nodig, extreem lage latentie, procesisolatie via standaard OS-rechten.
• Nadelen: Niet direct geschikt voor gedistribueerde of remote architecturen; één proces per client-sessie.

Server-Sent Events (SSE) met HTTP POST

Voor remote scenario's en microservices maakt MCP gebruik van SSE voor het ontvangen van server-naar-client berichten (zoals notificaties of langdurige antwoorden) in combinatie met reguliere HTTP POST-requests voor client-naar-server opdrachten. Tijdens de eerste HTTP GET-aanroep zet de server een permanente SSE-verbinding op en retourneert een uniek endpoint-URI (met sessie-ID) waarop de client opeenvolgende POST-berichten moet indienen.

De wisselwerking tussen protocol-gebaseerde tools en gesloten plugin-systemen vereist een helder inzicht; lees daarom meer over Claude skills en plugins in het juli-overzicht waarin we vergelijken hoe propriëtaire uitbreidingen zich verhouden tot open standaarden.

// Voorbeeld: JSON-RPC 2.0 tool-call request via HTTP POST /message?sessionId=a1b2c3d4
{
  "jsonrpc": "2.0",
  "id": 42,
  "method": "tools/call",
  "params": {
    "name": "execute_sql_query",
    "arguments": {
      "query": "SELECT id, status FROM deployments WHERE status = 'failed' LIMIT 5;"
    }
  }
}

3. SDK-Ecosysteem en Ondersteuning per Taal

De adoptiegraad van MCP wordt grotendeels gedreven door de beschikbaarheid van officiële en community-beheerde SDK's. Waar in de beginfase TypeScript en Python de enige volwaardige opties waren, zien we nu dat talen als Go, Rust, Kotlin en C# een inhaalslag hebben gemaakt.

Aangezien MCP-servers meestal worden aangestuurd door grotere orchestratie-layers, is het nuttig om de evaluatie van agent-orchestratie-frameworks uit juli 2026 te lezen om te begrijpen hoe planningsmodules de externe tools aanroepen. Mocht je twijfelen welk overkoepelend framework de beste ondersteuning biedt voor het afhandelen van deze protocol-streams, raadpleeg dan de vergelijking van agent- en LLM-frameworks waarin de ondersteuning voor MCP per bibliotheek overzichtelijk is gebenchmarkt.

De status van de verschillende SDK-implementaties is als volgt verdeeld:

• TypeScript SDK (Officieel): Meest volwassen implementatie. Ondersteunt zowel Browser-, Node.js- als Bun-runtimes. Volledige ondersteuning voor STDIO, SSE en custom transports. Bevat strikte Zod-schema-validatie.
• Python SDK (Officieel): Op basis van asyncio en Pydantic v2. Biedt zowel een high-level decorator-API voor snelle serverontwikkeling als low-level protocolafhandeling. Uitstekende integratie met FastMCP.
• Kotlin / Java SDK (Officieel): Gericht op enterprise-integraties en Spring Boot toepassingen. Ondersteunt asynchrone reactive streams (Project Reactor / Coroutines).
• Rust SDK (Community-driven / Officieel in wording): Biedt maximale performance en minimale geheugenfootprint, ideaal voor het draaien van MCP-servers op edge-hardware of in WASM-containers.

4. Beveiligingsmodel en Capability Negotiation

Toegang tot externe gereedschappen en bestandsbronnen brengt aanzienlijke veiligheidsrisico's met zich mee. Een kwaadwillende of verkeerd geconfigureerde MCP-server kan proberen de hostomgeving te compromitteren, terwijl een gecompromitteerde client onbevoegde acties kan uitvoeren via de server tools.

Het beveiligingsmodel van MCP rust op vier pijlers:

1. Expliciete Capability Negotiation: Tijdens de initialisatiefase moeten zowel client als server kenbaar maken welke features zij ondersteunen. Een server kan bijvoorbeeld eisen dat de client de roots capability ondersteunt voordat er bestandstoegang wordt verleend.
2. Human-in-the-Loop Approval: De specificatie schrijft voor dat de client-applicatie (de UI) de gebruiker expliciet om toestemming moet vragen voor gevoelige tool-executies, zoals het schrijven van bestanden, het uitvoeren van code of het wijzigen van infrastructurele resources.
3. Transportbeveiliging en Isolatie: Bij STDIO-servers vertrouwt de architectuur op het OS-rechtenmodel. Bij SSE-transports is TLS (HTTPS) verplicht, gecombineerd met OAuth2 of API-key tokens in de HTTP-headers.
4. Sandboxing: Wanneer je MCP-servers op afstand laat draaien, ontstaan er specifieke kwetsbaarheden rondom procesisolatie; bekijk de gids over agent-runtime-security van juli 2026 om te ontdekken hoe je sandboxing op Linux-hosts strak inricht.

Beveiligingsregel voor ontwikkelaars: Neem nooit aan dat de input van een tools/call argument gegarandeerd veilig is, zelfs niet als het gevalideerd is tegen het JSON Schema. Saniteer alle databasequeries, shell-commando's en bestandspaden op de MCP-server zelf.

5. Schema-validatie en Dynamische Resource Ontdekking

Een van de krachtigste aspecten van MCP is de dynamische aard van resources en tools. In plaats van statisch voorgedefinieerde endpoints kan een MCP-server op elk moment aan de client melden dat de lijst met beschikbare tools of resources is gewijzigd via de notifications/tools/list_changed of notifications/resources/list_changed methoden.

Voor resources hanteert MCP een URI-gebaseerd adresmodel, vergelijkbaar met REST. Een server kan bijvoorbeeld de volgende bronnen beschikbaar stellen:

• postgres://production-db/tables — Biedt een overzicht van tabellen als JSON-resource.
• file:///var/log/syslog — Biedt realtime log-access via text/plain streams.

Bij het declareren van tools wordt gebruikgemaakt van het **JSON Schema Draft 7**-formaat. Dit stelt LLM-orchestrators in staat om nauwkeurige parameter-parsing uit te voeren. Een voorbeeld van een robuuste tool-declaratie in TypeScript ziet er als volgt uit:

// Server-zijde tool declaratie met behulp van de TypeScript SDK
server.tool(
  "calculate_shipping_cost",
  {
    weight_kg: z.number().positive().describe("Gewicht van het pakket in kilogram"),
    destination_country: z.string().length(2).describe("ISO 3166-1 alpha-2 landcode"),
    express: z.boolean().default(false).describe("Kies voor spoedlevering")
  },
  async ({ weight_kg, destination_country, express }) => {
    const cost = await calculateRate(weight_kg, destination_country, express);
    return {
      content: [
        {
          type: "text",
          text: `De berekende verzendkosten bedragen €${cost.toFixed(2)}.`
        }
      ]
    };
  }
);

6. Prestatiemetingen en Latency-Analyse in Productie

In grootschalige agentic workflows is de latentie van tool-execution een kritieke factor. Elke keer dat een agent besluit een MCP-tool aan te roepen, worden er netwerk- of procesgrenzen overschreden. Om de impact van MCP op de totale responstijd te beoordelen, moet er onderscheid gemaakt worden tussen drie vertragingscomponenten:

1. Serialization & Deserialization Latency: De tijd die nodig is om de JSON-RPC payload te coderen en te decoderen. Bij grote payloads (bijvoorbeeld het inlezen van grote logbestanden via resources) kan dit oplopen tot enkele tientallen milliseconden.
2. Transport Overhead: STDIO heeft een te verwaarlozen overhead (< 1 ms). SSE via HTTP/2 of HTTP/3 introduceert netwerk RTT (Round Trip Time) en TLS-handshake overhead als de verbinding niet persistent gehouden wordt.
3. Execution Latency: De werkelijke runtime-duur van de onderliggende taak (bijv. een databasequery of API-call).

Om de foutmarges en latentie van MCP-aanroepen in kwantitatieve testsets vast te leggen, verwijzen we naar de gids voor het evalueren van AI-agents voor een concrete meetmethodologie.

7. Bekende Valkuilen en Anti-patterns

Tijdens de uitrol van MCP-servers in productie-omgevingen komen we een aantal terugkerende valkuilen tegen die de stabiliteit of veiligheid van de gehele agent-stack in gevaar brengen:

1. Over-exposure van Tools (Tool Bloat)

Het aanbieden van tientallen kleinschalige tools aan een LLM leidt tot verwarring bij het model (hallucinerende tool-calls) en een drastische toename in tokenverbruik bij elke prompt (omdat alle schemas in de context geladen moeten worden). Bündel gerelateerde functionaliteiten of maak gebruik van dynamische tool-filtering op basis van de huidige gebruikersintentie.

2. Staat-beheer op de MCP-server

MCP-servers moeten bij voorkeur **stateloos** ontworpen worden. Wanneer een server afhankelijk is van interne geheugenstatus tussen opeenvolgende tool-calls, gaat dit mis zodra de client herstart of wanneer er meerdere exemplaren van de server schalen achter een loadbalancer. Sla sessiestatus op in een externe cache (zoals Redis) en geef een sessietoken mee via de tool-arguments.

3. Ontbreken van Strict Schema Enforcement

Wanneer optionele velden niet correct gedefinieerd zijn in het JSON Schema, kunnen LLM's willekeurige datatypes meegeven. Gebruik altijd strikte schema-validatoren (zoals Zod of Pydantic) die ongeldige argumenten direct op protocolniveau afwijzen voordat de daadwerkelijke bedrijfslogica wordt aangeroepen.

8. Toekomstperspectief en Changelog-beleid

Het Model Context Protocol zal de komende jaren verder evolueren naar een universeel verbindingsstuk in de AI-infrastructuur. Belangrijke thema's die op de roadmap staan omvatten verbeterde ondersteuning voor streaming binaire data (zoals audio- en videostreams), fijnmazige OAuth-scoping per tool-niveau, en ingebouwde federatieve ontdekking van remote MCP-catalogi.

Als onderdeel van de **radar.llmnet.nl** continuïteit wordt deze pagina maandelijks bijgewerkt met de nieuwste versiestanden van de specificaties, SDK-releases en best practices uit de industrie. Ontwikkelaars worden aangemoedigd om regelmatig de changelog te controleren voor breaking changes in de onderliggende protocol-definitie.