MCP versus API: wanneer gebruik je MCP of directe HTTP

Wanneer je een AI-agent koppelt aan externe tools en API’s, zijn er twee algemene benaderingen: Model Context Protocol (MCP) gebruiken als abstractielaag, of een API rechtstreeks via HTTP aanroepen. Beide werken. Ze maken verschillende afwegingen rond flexibiliteit, complexiteit, prestaties en portabiliteit.

Deze post vergelijkt de twee benaderingen met concrete codevoorbeelden, latency-analyse en een besliskader om ertussen te kiezen.

De twee benaderingen

Directe HTTP-integratie

De AI-applicatie (of de backend ervan) roept externe API’s rechtstreeks aan met standaard HTTP-requests. De developer schrijft code om requests op te bouwen, authenticatie af te handelen, responses te parsen en resultaten terug te voeren naar de LLM.

┌──────┐     ┌────────┐                        ┌─────────────┐
│ User │────▶│ AI App │──── HTTP request ─────▶│ Weather API │
└──────┘     │        │◀─── JSON response ─────│             │
             │        │                        └─────────────┘
             │        │── result as context ──▶ LLM
             │        │◀── formatted answer ───
             └───┬────┘
                 │
                 ▼
           User gets answer

MCP-integratie

De AI-applicatie maakt verbinding met een MCP-server die de externe API verpakt. De applicatie gebruikt het MCP-protocol om beschikbare tools te ontdekken, ze op naam aan te roepen en resultaten te ontvangen. De MCP-server handelt de daadwerkelijke HTTP-calls naar de externe API af.

┌──────┐     ┌───────────────────┐              ┌────────────┐     ┌──────────┐
│ User │────▶│ AI App/MCP Client │── JSON-RPC ─▶│ MCP Server │────▶│ HTTP API │
└──────┘     │                   │◀─ JSON-RPC ──│            │◀────│          │
             │                   │              └────────────┘     └──────────┘
             │                   │── result as context ──▶ LLM
             │                   │◀── formatted answer ───
             └─────────┬─────────┘
                       │
                       ▼
                 User gets answer

Het belangrijkste verschil: bij directe HTTP is de AI-applicatie eigenaar van de API-integratiecode. Bij MCP is de MCP-server daar eigenaar van, en de AI-applicatie roept alleen tools op naam aan.

Je kunt de MCP-kant van dit diagram hebben zonder de server te bouwen: Quickchat AI host een streamable-HTTP MCP-server voor elke AI Agent, en je agent omzetten in een MCP-server komt neer op één URL plakken in de AI-app.

Codevergelijking

Laten we beide benaderingen vergelijken voor een praktisch voorbeeld: de repositories van een GitHub-gebruiker ophalen.

Directe HTTP-integratie

import httpx

async def get_user_repos(username: str, token: str) -> list[dict]:
    """Haal repositories op voor een GitHub-gebruiker."""
    async with httpx.AsyncClient() as client:
        response = await client.get(
            f"https://api.github.com/users/{username}/repos",
            headers={
                "Authorization": f"Bearer {token}",
                "Accept": "application/vnd.github.v3+json",
                "X-GitHub-Api-Version": "2022-11-28"
            },
            params={"sort": "updated", "per_page": 10}
        )
        response.raise_for_status()
        repos = response.json()
        return [
            {
                "name": r["name"],
                "description": r["description"],
                "stars": r["stargazers_count"],
                "language": r["language"],
                "url": r["html_url"]
            }
            for r in repos
        ]

Om dit met een LLM te integreren, heb je ook nodig:

• Een tooldefinitie in het formaat dat de LLM verwacht (OpenAI function calling-schema, Claude tool use-schema, enz.)
• Code om de tool call van de LLM te parsen, get_user_repos aan te roepen en het resultaat weer in het gesprek te injecteren
• Foutafhandeling voor HTTP-fouten, rate limits en verlopen authenticatie

MCP-server

from mcp.server.fastmcp import FastMCP
import httpx

mcp = FastMCP("github-server")

GITHUB_TOKEN = os.environ["GITHUB_TOKEN"]

@mcp.tool()
async def get_user_repos(username: str) -> str:
    """Haal de 10 meest recent bijgewerkte repositories op voor een GitHub-gebruiker.

    Args:
        username: GitHub-gebruikersnaam om op te zoeken
    """
    async with httpx.AsyncClient() as client:
        response = await client.get(
            f"https://api.github.com/users/{username}/repos",
            headers={
                "Authorization": f"Bearer {GITHUB_TOKEN}",
                "Accept": "application/vnd.github.v3+json",
                "X-GitHub-Api-Version": "2022-11-28"
            },
            params={"sort": "updated", "per_page": 10}
        )
        response.raise_for_status()
        repos = response.json()
        lines = []
        for r in repos:
            stars = r["stargazers_count"]
            lang = r["language"] or "onbekend"
            lines.append(f"- {r['name']} ({lang}, {stars} sterren): {r['description'] or 'Geen beschrijving'}")
        return "\n".join(lines)

if __name__ == "__main__":
    mcp.run(transport="stdio")

De MCP-versie kapselt de API-call, authenticatie en response-opmaak in de server in. Elke MCP-compatibele client kan deze tool gebruiken zonder iets te hoeven weten over de GitHub API.

Wat verandert er voor de AI-applicatie

Prestatievergelijking

MCP voegt een laag toe tussen de AI-applicatie en de externe API. Die laag heeft kosten.

Latency

Voor stdio transport (lokale MCP-servers) is de overhead minimaal: processtart bij het opstarten (eenmalig, doorgaans onder 100ms) en interprocescommunicatie per bericht (submilliseconde op moderne systemen). In de praktijk domineert de externe API-call de totale latency.

Voor remote MCP servers (Streamable HTTP of SSE) voeg je één HTTP round-trip toe tussen de client en de MCP-server, plus de HTTP round-trip van de MCP-server naar de externe API. Als de MCP-server en de externe API op dezelfde locatie staan, is deze overhead klein (enkele milliseconden). Als ze in verschillende regio’s staan, stapelt dit zich op. Het transport is echter zelden wat een gebruiker voelt: tijdens het bouwen van een helpcenter-agent op de gehoste MCP-server van Notion duurden 248 tool calls gemiddeld 2,7 seconden per stuk, bijna volledig door zoeken in Notion en het renderen van pagina’s, niet door de tussenliggende hop.

Voor de meeste use cases met AI-agenten, waarbij LLM-inferentie 500ms-5s duurt, is de MCP-overhead verwaarloosbaar.

Connection management

Directe HTTP: je applicatie beheert verbindingen naar elke externe API. Dit betekent connection pools, retry-logica en rate limiting per API afhandelen.

MCP: je applicatie beheert één verbinding per MCP-server. De server beheert de verbinding met de externe API. Als je 10 tools hebt verspreid over 3 MCP-servers, beheer je 3 verbindingen in plaats van 10.

Wanneer gebruik je MCP

Meerdere toolintegraties

Als je AI-applicatie verbinding moet maken met 5+ externe services, vermindert MCP de integratielast. In plaats van custom API-clients voor elke service te schrijven en te onderhouden, verbind je met MCP-servers (waarvan veel beschikbaar zijn als open-sourceprojecten).

Portabiliteit tussen AI-platforms

Als je MCP-servers bouwt voor je tools, werken die servers met elke MCP-client: Claude Desktop, Cursor, Windsurf, custom applicaties en platforms zoals Quickchat AI. Bij directe HTTP moet je tooldefinities opnieuw implementeren voor het formaat van elk platform.

Dynamische tooldiscovery

MCP ondersteunt runtime tooldiscovery via tools/list. Een AI-applicatie kan verbinding maken met een server en leren welke tools beschikbaar zijn zonder hardcoded configuratie. Dit is nuttig voor scenario’s waarin tools vaak veranderen of door gebruikers configureerbaar zijn.

Scheiding van verantwoordelijkheden

Als verschillende teams eigenaar zijn van verschillende tools, biedt MCP een duidelijke grens. Het team dat eigenaar is van de Salesforce-integratie bouwt en onderhoudt de Salesforce MCP-server. Het AI-applicatieteam maakt ermee verbinding zonder de API van Salesforce te hoeven begrijpen. Updates aan de Salesforce API worden afgehandeld in de MCP-server zonder de AI-applicatie aan te passen.

Wanneer gebruik je directe HTTP

Eén of twee integraties

Als je AI-agent maar één API hoeft aan te roepen (bijvoorbeeld een database-lookup), is de overhead van het draaien van een MCP-server onnodig. Een directe HTTP-call is eenvoudiger en heeft minder bewegende onderdelen.

Je hoeft de request ook niet met de hand te schrijven. De API Action-builder in gewone taal leest een gedocumenteerde REST API, genereert de methode, URL, parameters en beschrijving, en laat je vervolgens de echte response testen voordat je deze inschakelt.

Maximale controle over requests

MCP-servers abstraheren de HTTP-details. Als je precieze controle nodig hebt over requestconstructie (specifieke headers, queryparameters, request signing of niet-standaard authenticatie), geeft directe HTTP je die controle zonder tegen een abstractielaag te werken.

Latencygevoelige operaties

Als elke milliseconde telt (bijvoorbeeld realtime voice agents waarbij tool calls binnen strikte tijdsbudgetten moeten voltooien), elimineert het verwijderen van de MCP-laag één hop.

Niet-AI HTTP-calls

Als de HTTP-call niet door een AI-agent wordt getriggerd (bijvoorbeeld een backend cronjob die data synchroniseert), is MCP irrelevant. MCP is specifiek ontworpen voor communicatie van AI naar tool. Reguliere backendservices moeten reguliere HTTP-clients gebruiken.

Hybride benadering

Veel productiesystemen gebruiken beide. Het patroon:

• MCP voor toolintegraties die de AI-agent tijdens gesprekken aanroept (CRM-lookups, tickets aanmaken, knowledgebase-query’s)
• Directe HTTP voor interne backendoperaties, webhooks en system-to-system-communicatie

Zo werkt Quickchat AI intern. Het platform ondersteunt zowel HTTP Request Actions (directe API-calls met parameter-templating) als Remote MCP Actions (verbindingen met externe MCP-servers). Je kiest de juiste benadering voor elke integratie:

Voor een gedetailleerde vergelijking van hoe dit in de praktijk werkt, inclusief de verschillen tussen OpenAI’s GPT Actions en MCP, zie GPT Actions versus MCP.

Besliskader

Gebruik dit flowchart om te kiezen:

1. Roept de AI-agent de tool aan? Zo nee (het is een backendoperatie), gebruik directe HTTP.
2. Hoeveel externe tools heb je nodig? Bij 1-2 is directe HTTP eenvoudiger. Bij 3+ kun je MCP overwegen.
3. Bestaat er een vooraf gebouwde MCP-server voor de service? Zo ja, dan bespaart het gebruik ervan ontwikkeltijd.
4. Moet de integratie op meerdere AI-platforms werken? Zo ja, dan biedt MCP portabiliteit.
5. Is latency kritisch (budget van minder dan 100ms voor tool calls)? Zo ja, benchmark de MCP-overhead en beslis op basis daarvan.
6. Zijn verschillende teams eigenaar van verschillende integraties? Zo ja, dan helpt het server-per-integratie-model van MCP met eigendomsgrenzen.

In de praktijk wordt MCP steeds vaker de standaardkeuze als je een AI-agent bouwt die met externe services moet communiceren. Het ecosysteem van vooraf gebouwde servers is groot genoeg dat je vaak kunt beginnen zonder servercode te schrijven.

Verder lezen

• Verbind je AI Agent met een Remote MCP Server: Geef je agent live tools, stap voor stap
• Hoe Model Context Protocol werkt. MCP uitgelegd: Introductie tot MCP
• GPT Actions versus MCP: Vergelijking met de aanpak van OpenAI
• MCP-specificatie: De officiële protocolspecificatie
• HubSpot AI Actions: Voorbeeld van HTTP-gebaseerde AI-actions in de praktijk
• Het OpenAI Hugging Face-incident, wat er echt gebeurde: Het incident stap voor stap uitgelegd, en wat hacken echt betekent