MCP vs API voor AI-agenten

De misvatting

De term MCP vs API suggereert een vervanging, en het protocol nodigt uit tot lezen omdat het eruitziet als een API: een HTTPS-eindpunt, JSON, een lijst van aanroepbare operaties. Onder de motorkap is het JSON-RPC 2.0 over Streamable HTTP, wat betekent dat het een HTTP API is met een vaste berichtstructuur. Wat het standaardiseert is niet hoe je een systeem bereikt, maar hoe een AI-toepassing een systeem vraagt wat het kan doen, hoe het die dingen aanroept met een model dat de argumenten kiest, hoe fouten worden teruggegeven zodat het model zichzelf kan corrigeren, en hoe de persoon achter het model wordt geautoriseerd. Een REST API standaardiseert geen van dat, omdat het dat nooit nodig had: de aanroepers waren programma's waarvan de auteurs de documentatie één keer lazen.

Elke serieuze MCP-server voor een bedrijfsysteem is een laag bovenop de bestaande service-laag of API van dat systeem. De vraag is daarom niet welke te bouwen, aangezien je de API in beide gevallen nodig hebt, maar welke je aan een agent moet geven.

Wat een API een agent biedt, en wat niet

Geef een model een REST API en het kan deze gebruiken, met hulp. De hulp is het probleem. Iemand moet de eindpunten omzetten in functiedefinities die het model kan zien, in het formaat dat de modelprovider verwacht; de functiebellenformaten van Claude en OpenAI zijn vergelijkbaar maar niet identiek. Iemand moet de lus schrijven die de door het model gekozen functie neemt, het eindpunt aanroept met de juiste inloggegevens en de respons teruggeeft. Iemand moet beslissen hoe fouten het model bereiken, want een 422 met een validatiebody is niet iets dat een model goed leest, tenzij het wordt omgezet. En iemand moet autorisatie oplossen, want een API-sleutel in de omgeving van de agent maakt elke actie eruitzien als hetzelfde serviceaccount, niet de persoon die vraagt.

Geen van dit is moeilijk voor één systeem en één agent, wat de reden is dat het voor het protocol de standaard was. Het schaalt slecht. Elke combinatie van een agentproduct en een bedrijfsysteem is op maat gemaakt, de definities driften van de API, en er is geen manier voor een gebruiker van Claude of ChatGPT om zelf een systeem te verbinden. De API blijft uitstekend in waar het voor is gebouwd: hoge volumes, programma-naar-programma oproepen, bulkbewerkingen, webhooks en integraties waar de logica vastligt en de oproeper code is.

Wat MCP toevoegt

Het protocol beantwoordt elk van die hiaten met een regel die elke klant één keer implementeert. Ontdekking: tools/lijst geeft de tools met namen, beschrijvingen en JSON-schema's tijdens runtime terug, zodat het agentproduct geen voorafgaande kennis nodig heeft en de lijst kan veranderen naarmate apps worden geïnstalleerd of rollen veranderen. Aanroep: tools/oproep draagt een naam en argumenten; het resultaat bevat inhoud die het model leest, optionele gestructureerde inhoud, en een isFout flag that tells the model to correct and retry rather than give up. Authorisation: OAuth 2.1 with the token bound to the server and to the person, so the tool list and every call can be scoped to who is asking. Consent: annotations let a server say a tool is read-only, destructive or idempotent, and clients use them to decide when to confirm; a server can also return an input-required result to ask the person a question mid-call. Here is one call and its reply, as a client sends and receives them.

{
  "jsonrpc": "2.0",
  "id": 12,
  "method": "tools/call",
  "params": {
    "name": "recordPayment",
    "arguments": {
      "invoice_id": "9f1c2a6e-4b8d-4c1a-9e2f-2d7a1b6c5e10",
      "amount": 4850,
      "payment_date": "2026-09-18",
      "payment_reference": "BACS 41877"
    }
  }
}

{
  "jsonrpc": "2.0",
  "id": 12,
  "result": {
    "content": [
      { "type": "text", "text": "Payment recorded against INV-1057. Amount paid 4850.00 of 4850.00; status is now paid." }
    ],
    "structuredContent": {
      "invoice_id": "9f1c2a6e-4b8d-4c1a-9e2f-2d7a1b6c5e10",
      "number": "INV-1057",
      "amount_paid": 4850,
      "status": "paid"
    },
    "isError": false
  }
}

Een tools/oproepverzoek en resultaat voor een Sois-betalingsinstrument. Dezelfde operatie via de REST API zou een functiedefinitie vereisen die is geschreven voor de modelprovider, een lus om de oproep door te geven, en een beslissing over hoe de respons gepresenteerd moet worden; hier weet de klant al hoe hij alle drie moet doen.

Er zijn kosten aan verbonden. Het protocol is jonger dan REST en nog in ontwikkeling: de revisie van 2026-07-28 heeft sessies op protocolniveau verwijderd en veranderd hoe servers clients om input vragen, en clients moeten terugvallen op de vorige revisie voor servers. Hulplijsten verbruiken context, dus grote servers hebben uitgestelde laadtijd of hulponderzoek aan de clientzijde nodig. En een modelgestuurde oproeper is langzamer en minder voorspelbaar dan een programma, wat precies de reden is waarom je het niet zou gebruiken voor een nachtelijke synchronisatie.

Wanneer elk geschikt is

Hoe de belangrijkste agentproducten elk vandaag de dag gebruiken

De provider-API's regelen de vergelijking voor iedereen die zijn eigen agent bouwt, omdat beide nu een MCP-server accepteren als een eersteklas hulpmiddel naast gewone functieaanroepen. Aan de Claude-kant nemen aangepaste connectors in de web- en desktop-apps en Cowork een server-URL en voltooien OAuth in de app; Claude Code voegt een server toe met één commando; en de MCP-connector van de Messages API (beta, achter de mcp-client-2025-11-20 koptekst) neemt een mcp-servers entry and an mcp-toolset, supports tool calls only, and expects you to supply the access token. On the OpenAI side, ChatGPT's developer mode connects a remote server with OAuth or no authentication and asks for confirmation on write actions by default; the Responses API takes a tool of type mcp met een server_url, a goedkeuring vereist instelling en een optionele toegestane tools lijst, retourneert mcp_lijst_hulpmiddelen en mcp_oproep items, en werkt met Streamable HTTP of het oudere SSE transport.

Gewone functie-aanroepen blijven beschikbaar in beide API's, en het is het pad voor een REST-only systeem: je definieert de functies, je roept de API aan, je retourneert de resultaten. Het verschil zit volledig in wie de brug onderhoudt. Met MCP onderhoudt de eigenaar van het systeem één server en profiteert elke klant; met functie-aanroepen onderhoudt elke agentbouwer zijn eigen definities tegen de API.

Het patroon dat werkt: API eronder, MCP erboven

De systemen die dit goed doen, stellen beide bloot en leiden ze via dezelfde permissielaag. Sois is een implementatie van het patroon. De werkruimte heeft een servicelaag die elk scherm gebruikt. De MCP-server publiceert die laag als tools op één URL, gefilterd op de rol van de beller en opnieuw gecontroleerd bij elke oproep, met OAuth voor connectors en een bearer token voor scripts. Dezelfde werkruimte accepteert verzoeken in gewone taal op een aparte eindpunt voor bellers zonder agent, waar de eigen agent van de werkruimte de redenering doet en antwoord geeft via webhook of polling. En voor de uitgaande richting kan de eigen agent externe MCP-servers aanroepen via een gateway, onder dezelfde toelatings-, vraag- en weigeringsoverheid.

Niets in dat ontwerp vereist een keuze. De API bedient programma's, de MCP-server bedient modellen, de gateway bedient bellers zonder beiden, en één permissiemodel beheert alle drie. Wanneer iemand vraagt wat te bouwen, is het eerlijke antwoord dat de API een gegeven is en de MCP-server het is die het systeem bruikbaar maakt voor de agents die mensen al hebben.

Vragen die mensen stellen

Dit artikel wordt herzien wanneer de producten die het beschrijft veranderen. Volgende geplande herziening: 4 december 2026.