Een ontwikkelaarsgids beschrijft de afwegingen tussen het draaien van een Model Context Protocol (MCP) server op een workstation en het hosten ervan als een gedeelde HTTP-service. De auteur stelt dat de keuze de latentie, de blootstelling van inloggegevens en hoe gemakkelijk een team de AI-gestuurde data-accesslaag kan schalen, bepaalt.

Waarom de beslissing belangrijk is

MCP is de brug die ervoor zorgt dat assistenten met grote taalmodellen, zoals Claude of Cursor, SQL-opdrachten kunnen uitvoeren op een database zonder ooit het wachtwoord te zien. De assistent roept een tool aan, de tool stuurt het verzoek door naar een MCP-server, en de server voert de query uit. Als de server op de laptop van een ontwikkelaar draait, is de round-trip in feite een lokale functieaanroep. Als deze op een centrale host draait, gaat elk verzoek via het netwerk en is het onderhevig aan de authenticatie- en loggingmechanismen van de host. Teams die de overstap maken van een prototype voor een individuele ontwikkelaar naar een productieomgeving, moeten beslissen welk model het beste past bij hun beveiligingshouding, prestatieverwachtingen en operationele overhead.

De twee implementatiemodellen

Lokaal (stdio)

De client start de MCP-server op als een childproces en communiceert via standaard in- en uitvoer (stdio). Er is geen netwerkstack bij betrokken.

  • Ideaal voor: individuele ontwikkelaars, snelle experimenten en lokale testdatabases.
  • Voordelen: de latentie is vrijwel nihil; het proces erft de omgeving van de gebruiker, waardoor wachtwoorden de machine nooit verlaten.
  • Nadelen: elke gebruiker moet zijn eigen configuratiebestand of omgevingsvariabelen bijhouden; er is geen centraal audit trail; schalen naar meerdere gebruikers vereist het repliceren van de setup op elke workstation.

Remote (HTTP)

De server draait continu op een host die bereikbaar is via HTTP. Clients authenticeren zich, meestal via een OAuth-achtige flow, en sturen verzoeken naar een bekend endpoint.

  • Ideaal voor: teams, CI-pipelines en productiedata die door meerdere mensen of services moet worden geraadpleegd.
  • Voordelen: één centraal punt voor auditlogs, role-based access control en connection pooling; inloggegevens worden één keer opgeslagen in een beveiligde vault.
  • Nadelen: extra infrastructuur om te voorzien en te onderhouden; netwerklatentie voegt enkele milliseconden toe per round-trip.

Directe vergelijking

Aspect Lokaal Remote
Doelgebruik Eén gebruiker Meerdere gebruikers
Authenticatie Omgevingsvariabelen of lokale configuratie OAuth-compatibele tokenflow
Auditing Geen ingebouwde functie Centraal logboek registreert elk verzoek
Configuratiecomplexiteit Minimaal Vereist server provisioning, TLS, tokenbeheer
Latentie Bijna nul Hoger door netwerkverkeer
Blootstelling van inloggegevens Beperkt tot de machine van de ontwikkelaar Gecentraliseerd, maar moet beschermd worden tegen datalekken

Een pragmatische hybride aanpak

De meeste organisaties kiezen niet voor één model en blijven daar voor altijd bij. De gids raadt een gefaseerde uitrol aan:

  1. Ontwikkel lokaal – start een lokale MCP-server op tegen een sandbox-database. De snelheid stimuleert snelle iteratie en houdt geheimen buiten het versiebeheer.
  2. Stap over naar remote – zodra de codebase wordt gedeeld, verplaats je de server naar een centrale host. Pas de clientconfiguratie aan om naar het HTTP-endpoint te wijzen en schakel OAuth in.
  3. Beveilig productie – houd productiedatabases achter een remote, controleerbare gateway. Dwing read-only rollen af voor de AI-assistent en sla productiewachtwoorden alleen op in een secrets manager waar de remote server toegang toe heeft.

Veelvoorkomende valkuilen om te vermijden

  • Het opslaan van productiewachtwoorden in een .env-bestand van een ontwikkelaar of andere lokale configuratie. Als de machine gecompromitteerd wordt, ligt de database bloot.
  • Het implementeren van een remote MCP-server zonder OAuth of een vergelijkbaar tokensysteem. Plain-text basic auth of statische API-keys lekken gemakkelijk.
  • De AI-assistent schrijfrechten geven op productietabellen. Zelfs per ongeluk uitgevoerde DELETE-statements kunnen leiden tot gegevensverlies; een read-only rol elimineert dit risico.

Wanneer lokaal nog steeds zinvol is

Als de workflow van een team nooit een enkele machine verlaat — denk aan een solo data scientist die prototypes maakt op een persoonlijke laptop — blijft lokale implementatie de eenvoudigste en snelste optie. De overhead van het instellen van TLS-certificaten, tokenuitgifte en een logging-pipeline is mogelijk niet gerechtvaardigd voor een kortstondig experiment.

De kern

Als je pure snelheid nodig hebt en de enige gebruiker bent, is een lokale MCP-server de meest eenvoudige keuze. Als je controleerbaarheid, gedeelde toegang of beveiliging op productieniveau nodig hebt, is een remote HTTP-server de enige levensvatbare weg. De meeste teams beginnen lokaal vanwege het gemak, en gaan dan over naar een remote, met tokens beveiligde gateway voordat ze met productiedata werken. Stem het implementatiemodel af op de projectfase en het risicoprofiel van de gegevens die je blootstelt.