Wanneer vragen MCP-clients toestemming? Vergelijking 2026

2026-09-29

Elke MCP-client die er in 2026 toe doet, vraagt het voordat een assistent een tool uitvoert die iets verandert. Dat deel van het antwoord is saai en geruststellend. Het nuttige deel is wat er na de eerste vraag gebeurt, want niemand klikt lang veertig keer per dag op "Allow": elke client biedt een manier om niet meer gevraagd te worden, en de clients verschillen sterk in hoe smal die manier is.

Kort gezegd: met Claude Code, Zed, Cursor en Devin Desktop keurt u afzonderlijke MCP-tools vooraf bij naam goed. Codex, de motor achter de ChatGPT-desktop-app, kan in plaats daarvan beslissen op basis van de labels van de server zelf — en vragen bij alles wat niet als alleen-lezen is gemarkeerd. VS Code doet beide op dialoogniveau en voegt schakelaars voor de hele werkruimte toe. Geen van deze ontwerpen is verkeerd, maar ze falen op verschillende manieren, en welk falen voor u telt, hangt af van wie de server heeft geschreven.

Deze vergelijking staat naast ons overzicht van welke MCP-clients een lokale server kunnen draaien. Dat overzicht beantwoordt "start hij wel"; dit stuk beantwoordt "wat doet hij als de assistent besluit iets te veranderen". Alles hieronder is op 29 september 2026 gecontroleerd aan de hand van de documentatie van elke leverancier.

Het korte antwoord

Twee kolommen dragen de meeste betekenis. "Fijnste blijvende toestemming" vertelt of u search kunt vertrouwen zonder share te vertrouwen. "Beslist op basis van annotaties" vertelt of de client die splitsing voor u maakt — met labels die de server over zichzelf heeft geschreven.

Codex en de ChatGPT-desktop-app: vier modi en een label

Codex heeft het meest expliciete ontwerp, en omdat de ChatGPT-desktop-app, Codex CLI en de IDE-extensie één configuratiebestand delen, geldt het voor alle drie. Elke MCP-server krijgt een default_tools_approval_mode, en elke tool kan die overschrijven met tools.<tool>.approval_mode. De gedocumenteerde waarden zijn auto, prompt, writes en approve.

De interessante is writes. In de woorden van OpenAI "vraagt hij om bevestiging voor tools die niet als alleen-lezen zijn gemarkeerd". Zoeken gebeurt stil, al het andere stopt en vraagt, en een tool zonder enige annotatie telt als schrijfactie — de veilige standaard als een server niets zegt. Bovenop de modi zegt de goedkeuringsdocumentatie van Codex dat destructieve MCP-toolaanroepen altijd goedkeuring vereisen als de tool een destructieve annotatie opgeeft, tenzij hij ook een lees-annotatie opgeeft.

Eén wijziging om te kennen als u een oudere configuratie hebt: Codex ondersteunt approval_policy = "untrusted" niet meer, en de uitgefaseerde instelling kan verhinderen dat de client start. Vertrouwen in een project stelt u nu in plaats daarvan in met het trust_level van het project.

ChatGPT op het web werkt volgens hetzelfde principe. In de ontwikkelaarsmodus, beschikbaar voor Pro-, Plus-, Business-, Enterprise- en Education-accounts, "vereisen schrijfacties standaard bevestiging"; ChatGPT respecteert readOnlyHint en behandelt elke tool zonder die hint als schrijfactie. Een keuze kan per tool worden onthouden voor de rest van een gesprek, en niet langer.

Claude Code en Claude Desktop: regels die u bij naam schrijft

Claude Code leest geen annotaties om te beslissen. Het gebruikt toestemmingsregels in drie lijsten — allow, ask en deny — die in een vaste volgorde worden geëvalueerd: eerst deny, dan ask, dan allow. MCP-tools heten mcp__<server>__<tool>, dus mcp__notes__search staat één tool toe, mcp__notes__get_* een familie, en mcp__notes of mcp__notes__* dekt de hele server. De standaardmodus heet nu Manual; tot de ruimere modi behoren acceptEdits, auto, waarin een classifier de acties beoordeelt in plaats van u, en bypassPermissions.

Twee details neigen naar veiligheid. Servers uit de gecommitte .mcp.json van een project hebben uw goedkeuring nodig voordat ze überhaupt verbinden. En een serverauteur kan een tool markeren met _meta["anthropic/requiresUserInteraction"], waarna Claude Code bij elke aanroep zijn vraag toont — zelfs in acceptEdits, auto en bypassPermissions.

De connectorinstellingen van Claude Desktop, onder Customize → Connectors, groeperen de tools van een server in categorieën zoals alleen-lezen en schrijven/verwijderen, en elke categorie of afzonderlijke tool kan op Always allow, Needs approval of Blocked worden gezet.

Cursor, VS Code, Zed en Devin Desktop: de editors

Cursor zegt het zonder omwegen: "Cursor vraagt standaard om goedkeuring voordat het MCP-tools gebruikt." MCP volgt dezelfde Run Modes als terminalcommando's. In Auto-review draaien aanroepen op de allowlist meteen en gaat al het andere langs een classifier-model; Run Everything voert elke toolaanroep uit zonder te vragen. De allowlist neemt server:tool-items met wildcards. Eén valkuil: laat u de tool-allowlist van een server leeg, dan zijn alle tools van die server toegestaan.

VS Code noemt zijn standaardniveau Manual permissions: alles wat niet automatisch is goedgekeurd, vraagt om bevestiging. In het dialoogvenster keurt u één gebruik goed of verleent u goedkeuring voor de sessie, de werkruimte of alle toekomstige aanroepen, en goedkeuringen per tool kunnen voor elke MCP-server worden ingesteld. Allow all haalt de vragen volledig weg, en Assisted permissions, waarbij een model elke aanroep beoordeelt, is als experimenteel gemarkeerd. Eén uitzondering verdient aandacht: MCP-servers die in een agent-plugin meekomen, "worden impliciet vertrouwd wanneer u de plugin installeert" en slaan de aparte vertrouwensvraag bij het starten over. Het installeren van de plugin is de vertrouwensbeslissing.

Zed heeft het best leesbare regelsysteem. agent.tool_permissions.default staat op confirm tenzij u het wijzigt, met allow en deny als alternatieven. Regels noemen MCP-tools mcp:<server>:<tool_name> en kunnen worden ingesteld op altijd toestaan, altijd bevestigen of altijd weigeren, waarbij weigeren voorgaat. De vraag zelf biedt "Allow once", "Deny once" en "Always for" de tool; voor MCP-tools bestaat alleen de optie op toolniveau.

Devin Desktop, het vroegere Windsurf, veranderde samen met zijn naam ook van model. Zijn agent, Devin Local, "vervangt de niveaus voor automatische uitvoering door een fijnmaziger toestemmingssysteem", en standaard vraagt hij het voordat hij welke MCP-tool dan ook aanroept. Vanuit de vraag kunt u één tool of alle tools van die server toestaan, voor de sessie of permanent, en Deny-regels gaan boven alles. Enterprise-beheerders kunnen specifieke servers of tools vooraf goedkeuren voor de hele organisatie.

Wat annotaties wel en niet kunnen

De MCP-specificatie geeft servers een vocabulaire om hun tools te beschrijven: readOnlyHint, destructiveHint, idempotentHint, openWorldHint. Ze vertelt clients ook hoe ver ze die moeten geloven: clients "MOETEN toolannotaties als onbetrouwbaar beschouwen, tenzij ze van vertrouwde servers komen". En ze vraagt om een mens in de lus die elke toolaanroep kan weigeren.

Dat zet de twee ontwerpen hierboven in perspectief. Een client die op basis van annotaties beslist, zoals de modus writes van Codex, is handig bij een server die u vertrouwt: u configureert één regel, en voor elke nieuwe schrijvende tool die de server toevoegt, wordt automatisch gevraagd. Bij een server die u niet vertrouwt, is hij precies zo veilig als de eerlijkheid van die server. Een tool die gegevens wijzigt en zichzelf alleen-lezen noemt, draait zonder vraag.

Een client die u tools laat benoemen, zoals Claude Code of Zed, faalt de andere kant op. Het maakt hem niet uit wat de server beweert, maar een nieuwe schrijvende tool uit een update valt er alleen onder als uw regel breed genoeg was om hem te vangen — of smal genoeg om hem te missen en terug te vallen op vragen. Regels op naam zijn het veiligst als ze luiden "sta deze leesacties toe", niet "sta deze server toe".

Een verstandige opzet voor een server die leest en schrijft

Welke client het ook is, dezelfde vier gewoonten dekken het grootste deel van het risico:

1. Sta leesacties bij naam toe, niet de hele server. Zoeken en transcripties lezen is wat een assistent de hele dag doet; daar kost een vraag het meest en beschermt ze het minst.
2. Laat een vraag staan op alles wat deelt of vervangt. Publiceren voor andere mensen en tekst overschrijven zijn de twee soorten wijzigingen die u niet ongedaan maakt door een waarde terug te zetten.
3. Vertrouw alleen op annotaties bij servers die u vertrouwt. Voor een server uit een register dat u nooit hebt gebruikt, noemt u de tools liever in regels.
4. Geef een minder vertrouwde client een alleen-lezen-instantie. Ondersteunt de server een alleen-lezen-modus, dan kan één client tot lezen worden beperkt terwijl een andere volledige toegang houdt.

Waarschuwingssignalen: een allowlist-item in Cursor voor een server met een lege toollijst, een VS Code-plugin die niemand in het team heeft bekeken, en "Always allow" aangeklikt bij een tool waarvan u de naam niet hebt gelezen.

Hoe dit eruitziet in Speak-Y

De Speak-Y MCP-server is geschreven voor beide soorten clients. Leestools — opnames doorzoeken, transcripties, samenvattingen en actiepunten lezen, tags en kanalen opsommen — dragen readOnlyHint en lezen de bibliotheek rechtstreeks van uw machine. Tools die iets veranderen — tags, titels, sprekersnamen, opnieuw transcriberen, delen in een teamkanaal — zijn als gegevenswijzigend gedeclareerd en lopen via de draaiende Speak-Y-app, waar elke aanroep wordt gelogd en waar ze kunnen worden uitgeschakeld.

Twee ervan zijn bewust gemarkeerd met destructiveHint: retranscribe, omdat het de huidige tekst van een opname vervangt, inclusief handmatige correcties, en share_to_channel, omdat collega's een opname kunnen lezen voordat u die terugtrekt. In de modus writes van Codex komen die vragen zonder enige configuratie; in Claude Code of Zed staat u de leestools bij naam toe en laat u de rest op ask.

Wilt u liever dat een client alleen kan lezen, start de server dan met --read-only in de configuratie van die client: de wijzigende tools worden helemaal niet aan hem gepubliceerd, dus er valt niets per ongeluk goed te keuren. Instellen is één klik vanuit Instellingen → Integraties, en de MCP-server is gratis op elk plan, ook op Free.

De goedkeuringsvraag is maar één van de controles die een schrijvende assistent veilig in gebruik maken. De andere — welke wijzigingen omkeerbaar zijn en wat het logboek bewaart — komen aan bod in wat MCP-schrijftoegang veilig maakt, en de MCP-documentatie bevat de configuratie per client.

FAQ

Vragen MCP-clients toestemming voordat ze een tool uitvoeren die gegevens wijzigt?

Elke grote client vraagt het standaard. Claude Code, Cursor, VS Code, Zed en Devin Desktop vragen om bevestiging voordat een MCP-tool draait, totdat u die vooraf goedkeurt, en de ontwikkelaarsmodus van ChatGPT vereist bevestiging voor elke tool die niet als alleen-lezen is gemarkeerd. Het verschil zit in hoe fijnmazig u daarna vooraf kunt goedkeuren: per tool, per server, per sessie of voorgoed. Gecontroleerd op 29 september 2026.

Welke MCP-clients gebruiken de annotatie readOnlyHint om te bepalen wanneer ze vragen?

Codex en ChatGPT doen dat expliciet. De goedkeuringsmodus writes van Codex vraagt om bevestiging voor tools die niet als alleen-lezen zijn gemarkeerd en vraagt altijd voor een tool die zichzelf destructief noemt, en de ontwikkelaarsmodus van ChatGPT behandelt elke tool zonder readOnlyHint als schrijfactie. Claude Code, Cursor, VS Code en Zed documenteren annotaties niet als input voor goedkeuring; daar schrijft u de regels zelf, op toolnaam.

Kan ik leestools automatisch goedkeuren en toch een vraag krijgen vóór schrijfacties?

Ja, in elke client in deze vergelijking, maar het mechanisme verschilt. In Claude Code, Zed, Cursor en Devin Desktop staat u de leestools bij naam toe, zoals mcp__server__search in Claude Code of mcp:server:search in Zed. In Codex regelt de modus writes het in één regel, waarbij hij erop vertrouwt dat de server zijn leestools eerlijk markeert.

Zijn toolannotaties zoals readOnlyHint een veiligheidsgarantie?

Nee. De MCP-specificatie zegt dat clients toolannotaties als onbetrouwbaar moeten beschouwen, tenzij ze van vertrouwde servers komen. Een server die een schrijvende tool als alleen-lezen markeert, ondermijnt elk clientbeleid dat op die hint is gebouwd. Zie annotaties als gemak voor servers die u al vertrouwt, en noem tools expliciet in regels voor de servers die u niet vertrouwt.

Wat is de veiligste manier om een server met vergadernotities aan een AI-assistent te koppelen?

Keur alleen de leestools vooraf goed, laat een vraag staan op alles wat gegevens wijzigt, en geef clients die u minder vertrouwt een alleen-lezen-instantie. Bij Speak-Y haalt het starten van de server met --read-only in de configuratie van één client de wijzigende tools voor die client volledig weg, terwijl een andere client volledige toegang houdt met zijn eigen vragen.