Een lokale MCP-server en een externe zien er in bedrijf identiek uit: dezelfde toollijst in de client, hetzelfde gesprek, hetzelfde resultaat. Het verschil zit in wat u hebt afgegeven om er te komen. Een lokale server is een programma op uw machine dat de client start en waarmee hij praat via standaardinvoer en -uitvoer, en wat u afgeeft is een opdrachtregel. Een externe server is het HTTPS-endpoint van iemand anders, en wat u afgeeft is een credential — samen met alles wat die ontsluit, zolang u hem in leven laat.
De nuttige vraag voordat u een URL in een connectordialoog plakt, is daarom niet "is deze server te vertrouwen", want dat kan niemand van een vermelding aflezen. Het zijn drie nauwere vragen die wel een op te zoeken antwoord hebben: waartoe het token is beperkt, waar u het weer intrekt, en wat de catalogus waarin u de server vond werkelijk heeft gecontroleerd. De antwoorden hieronder gaan uit van de MCP-specificatie en de documentatie van leveranciers zoals die er op 16 augustus 2026 bij stonden.
De huidige revisie van de specificatie, 2026-07-28, behandelt de twee transporten als verschillende beveiligingscontexten. Autorisatie is in MCP optioneel, en waar ze geldt is expliciet vastgelegd: implementaties met een HTTP-transport zouden zich aan de OAuth-specificatie moeten houden, terwijl stdio-implementaties die helemaal niet zouden moeten volgen en credentials in plaats daarvan uit de omgeving halen. HTTP+SSE, het oudere externe transport, is afgeschaft; Streamable HTTP is wat u kunt verwachten.
| Lokaal (stdio) | Extern (Streamable HTTP) | |
|---|---|---|
| Wat u afgeeft | Een commando dat uw client zal uitvoeren | Een URL, en meestal een OAuth-toestemming |
| Waar de code draait | Uw machine, uw gebruikersaccount | Infrastructuur die iemand anders beheert |
| Credentials | Uit de omgeving gehaald | Toegangstoken gebonden aan die ene server |
| Wat "disconnect" doet | Er wordt geen proces meer gestart | Wist de tokenkopie van de client; de toestemming kan blijven bestaan |
| Ergste geval bij een kwaadwillende auteur | Willekeurige code met uw rechten | Alles wat de goedgekeurde scopes bereiken |
Geen van beide kolommen is de veilige. Een lokale server is willekeurige code die onder uw account draait — precies daarom eist de specificatie dat een client die lokale configuratie met één klik aanbiedt, het exacte commando dat hij zal uitvoeren ongekort toont en vooraf uitdrukkelijke goedkeuring vraagt. Een externe server zet geen code op uw machine, maar verplaatst uw gegevens naar een beheerder en laat een toegangspad achter dat uw aandacht overleeft. De twee falen in verschillende richtingen; onze vergelijking van wat elk soort kan zien gaat daar dieper op in.
Het autorisatiemodel is OAuth 2.1, en het deel dat u als gebruiker moet
begrijpen is de binding aan één ontvanger. Clients moeten Resource Indicators
for OAuth 2.0 (RFC 8707) implementeren: de parameter resource moet zowel in de
autorisatie- als in de tokenaanvraag worden meegestuurd en noemt de specifieke
server waarvoor het token bedoeld is. Servers moeten controleren dat tokens voor
hen zijn uitgegeven, alleen tokens accepteren die geldig zijn voor hun eigen
resources, en mogen geen andere accepteren of doorgeven. Het token van een
client doorgeven aan een achterliggende API — "token passthrough" — is ronduit
verboden.
Een correct geïmplementeerd token is bij een andere server dus waardeloos. Dat sluit replay, hergebruik van credentials tussen diensten en een klasse van confused-deputy-aanvallen af — en zegt helemaal niets over de beheerder zelf. De binding aan één ontvanger zegt waar het token werkt, niet wat het bedrijf aan de andere kant doet met wat zijn tools namens u ophalen. Dat staat in hun privacyverklaring, niet in het protocol.
Bij de scopes wordt uw blootstelling werkelijk beslist. De specificatie duwt
servers richting minimale rechten: scopes_supported hoort de kleinste set te
zijn die de basisfunctie nodig heeft, en al het meerdere wordt stapsgewijs
gevraagd zodra een bevoorrechte bewerking voor het eerst wordt geprobeerd.
Servers die zich daaraan houden vragen vooraf weinig; servers die dat niet doen
tonen één toestemmingsscherm met alles erop. Dat scherm is het laatste punt
waarop de beslissing bij u ligt.
Er zijn twee plekken om in te trekken, en de meeste mensen gebruiken alleen de eerste.
In de assistent. In Claude staan eigen connectors onder Customize > Connectors; daar voegt u er een toe door de server-URL te plakken, en op Free is er maar één toegestaan. Op diezelfde pagina verbreekt u de verbinding en zet u de afzonderlijke tools van de server aan of uit in plaats van ze allemaal te accepteren. Anthropic benoemt de vertrouwenspositie onomwonden in zijn helpcentrum: eigen connectors verbinden Claude met willekeurige diensten die Anthropic niet heeft geverifieerd. In ChatGPT komen externe servers binnen via de ontwikkelaarsmodus — Settings → Security and login, op het web, met SSE- en streaming-HTTP-endpoints. De documentatie van OpenAI noemt het krachtig maar gevaarlijk, noemt prompt injection en destructieve schrijfacties onder de risico's, en vraagt voor schrijfacties standaard om bevestiging.
Bij de dienst waarmee u hebt geautoriseerd. Dit is de plek die wordt overgeslagen. De connector verwijderen haalt de tokenkopie van uw client weg; de toestemming die in uw account bij Google, GitHub, Atlassian of Notion is vastgelegd, is een apart object met een eigen levensduur, en een bijbehorend refresh-token kan de connector ruimschoots overleven. De richtlijn van Anthropic zegt precies dat — intrekken door de connector in de instellingen van Claude of in de beveiligingsinstellingen van de externe dienst te verbreken. Doe beide, en zoek die pagina met gekoppelde apps op voordat u koppelt.
De officiële MCP-registry op registry.modelcontextprotocol.io is de voor de
hand liggende plek om servers te vinden, en het is makkelijk om in een
vermelding meer te lezen dan er staat. Het charter van de werkgroep is daar
precies over. Publicatie en vertrouwen dekken authenticatiestromen — GitHub
OAuth, GitHub OIDC, DNS- en HTTP-verificatie — plus eigendom van namespaces,
moderatiegereedschap en meldingen vanuit de gemeenschap. Uitdrukkelijk buiten de
scope: MCP-serverimplementaties rangschikken of ertussen kiezen namens clients
of eindgebruikers, en servercode hosten, distribueren of uitvoeren, want de
registry is een metadatacatalogus en geen pakketregister.
Een geverifieerde namespace bewijst dus dat degene die de vermelding publiceerde, de GitHub-organisatie of het domein in die naam beheert. Dat is een echt signaal: het maakt typosquatting lastiger en geeft u iemand om verantwoordelijk te houden. Het is geen codereview, geen beveiligingsaudit en geen aanbeveling — identiteit vastgesteld, gedrag nog onbekend.
Eén principe uit de specificatie is het waard om elke verbinding mee in te gaan: beschrijvingen van toolgedrag, annotaties inbegrepen, gelden als niet te vertrouwen tenzij ze van een vertrouwde server komen, en hosts moeten uitdrukkelijke toestemming van de gebruiker krijgen voordat ze een tool aanroepen. Een toolbeschrijving is tekst die een externe partij schrijft en uw model leest — de definitie van niet-vertrouwde invoer, en de reden dat "de server zei dat hij alleen-lezen was" geen beveiligingsmaatregel is.
Het concrete precedent is CVE-2025-6514, gepubliceerd op 9 juli 2025 tegen
mcp-remote, de proxy waarmee veel clients externe servers bereikten. Met een
score van 9,6 liet die een kwaadwillende server OS-commando's injecteren op de
machine die verbinding maakte, via een geprepareerde waarde van
authorization_endpoint in de OAuth-stroom — de versies 0.0.5 tot en met 0.1.16
waren getroffen, opgelost in 0.1.16. In een chat hoefde niets te worden
goedgekeurd: het verbinden was de hele aanval. Alles wat een externe server
stuurt, zijn gegevens die uw software verwerkt, en de verbinding zelf hoort bij
uw aanvalsoppervlak.
Al het bovenstaande is de prijs voor het bereiken van iets dat werkelijk in andermans cloud leeft — uw issue tracker, uw CRM, uw agenda. Voor die dingen is dat een redelijke prijs en voor bestanden die al op uw schijf staan een vreemde; daarom levert Speak-Y een lokale server in plaats van een gehost endpoint.
De MCP-server is een proces dat uw client op uw machine start. Voor lezen hoeft
er verder niets te draaien: zoekresultaten, transcripties, vergadersamenvattingen
en action items komen rechtstreeks uit de bibliotheek op dezelfde computer,
zonder uitgegeven token en zonder relay ertussen. Commando's die iets wijzigen —
een opname taggen, sprekers benoemen, delen in een teamkanaal — lopen via de
draaiende app, worden aan uw client als gegevenswijzigend gemeld zodat hij eerst
vraagt, en worden gelogd op de plek waar u ze ook kunt uitzetten. --read-only
aan de argumenten van de server toevoegen betekent dat de wijzigende commando's
helemaal niet aan die client worden aangeboden — een sterkere garantie dan een
beschrijving die goed gedrag belooft. Installeren is één klik vanuit
Instellingen → Integraties, gratis op elk plan, ook op Free.
De ruil gaat twee kanten op: een lokale server kan ChatGPT in een browsertabblad niet bedienen, en hij draait alleen waar de app draait. Weegt die beperking zwaar, dan is welke clients een lokale server überhaupt kunnen starten de vergelijking om hierna te lezen — en is de vraag wat een assistent na het koppelen mag wijzigen, dan behandelt waar de grens bij schrijftoegang ligt dat. Het MCP-overzicht somt op wat de server van Speak-Y aanbiedt.
Een lokale server is een programma op uw eigen machine dat de client start en waarmee hij praat via standaardinvoer en -uitvoer: wat u afgeeft is een opdrachtregel, en er wordt geen token uitgegeven. Een externe server is een HTTPS-endpoint dat iemand anders beheert: wat u afgeeft is een credential, meestal een OAuth 2.1-toegangstoken, en de gegevens die de tools aanraken reizen naar de infrastructuur van die beheerder.
Volgens de autorisatiespecificatie van MCP is het token gebonden aan één server en één set scopes. Clients moeten een RFC 8707 resource indicator meesturen die de server noemt, zowel in de autorisatie- als in de tokenaanvraag, en de server moet controleren dat tokens voor hem zijn uitgegeven — hij mag geen ander token accepteren of doorgeven. Dat voorkomt dat het token bij een andere dienst opnieuw wordt gebruikt. Over wat de beheerder doet met de gegevens die zijn tools namens u ophalen, zegt het niets.
Op twee plekken, en de meeste mensen doen alleen de eerste. De connector in uw assistent verwijderen wist de tokenkopie van de client; de OAuth-toestemming die is vastgelegd bij de dienst waarmee u hebt geautoriseerd, is een apart object en blijft meestal bestaan. Anthropic adviseert rechten in te trekken door de connector te verbreken in de instellingen van Claude of in de beveiligingsinstellingen van de externe dienst. Zoek de pagina met gekoppelde apps van de aanbieder op vóór het koppelen, niet erna.
Nee. De registry verifieert eigendom van de namespace — een io.github.*-naam via authenticatie bij GitHub, een domeingebaseerde naam via DNS- of HTTP-verificatie — waarmee is aangetoond dat de uitgever die naam beheert. Het charter plaatst het rangschikken of kiezen tussen serverimplementaties uitdrukkelijk buiten de scope en stelt dat de registry een metadatacatalogus is en geen pakketregister: hij host, distribueert en voert geen servercode uit.
Alleen wat de door u goedgekeurde scopes bereiken. Het risico is dat de scopes ruimer zijn dan de taak: een token dat voor een hele mailbox of schijf is verleend, staat ter beschikking van elke tool die die server aanbiedt, zolang de toestemming bestaat. Lees het toestemmingsscherm in plaats van de marketingpagina en gebruik regelaars per tool waar de client die heeft — in de connectorinstellingen van Claude kunt u afzonderlijke tools aan- en uitzetten, en de ontwikkelaarsmodus van ChatGPT vraagt standaard om bevestiging voor schrijfacties.