Clientes MCP: qué preguntan antes de que la IA cambie sus datos (2026)

2026-09-29

Todo cliente MCP que importa en 2026 pregunta antes de que un asistente ejecute una herramienta que cambia algo. Esa parte de la respuesta es aburrida y tranquilizadora. La parte útil es lo que pasa después de la primera confirmación, porque nadie hace clic en «Permitir» cuarenta veces al día durante mucho tiempo: cada cliente ofrece una manera de dejar de preguntar, y los clientes difieren mucho en lo precisa que es esa manera.

En resumen: Claude Code, Zed, Cursor y Devin Desktop permiten aprobar de antemano herramientas MCP concretas por su nombre. Codex, el motor de la aplicación de escritorio de ChatGPT, puede decidir en cambio a partir de las etiquetas del propio servidor: preguntar por todo lo que no esté marcado como de solo lectura. VS Code hace ambas cosas desde el diálogo y añade interruptores para todo el espacio de trabajo. Ninguno de estos diseños es erróneo, pero fallan de maneras distintas, y el fallo que debe preocuparle depende de quién escribió el servidor.

Esta comparativa acompaña a nuestro repaso de qué clientes MCP pueden ejecutar un servidor local. Aquel responde a «¿arrancará?»; este responde a «¿qué hará cuando el asistente decida cambiar algo?». Todo lo que sigue se comprobó en la documentación de cada fabricante el 29 de septiembre de 2026.

La respuesta corta

Dos columnas concentran casi todo el significado. «Permiso permanente más fino» indica si puede confiar en search sin confiar en share. «¿Decide por anotaciones?» indica si el cliente hace esa división por usted, usando etiquetas que el servidor escribió sobre sí mismo.

Codex y la aplicación de escritorio de ChatGPT: cuatro modos y una etiqueta

Codex tiene el diseño más explícito y, como la aplicación de escritorio de ChatGPT, Codex CLI y la extensión para el IDE comparten un mismo archivo de configuración, sirve para los tres. Cada servidor MCP recibe un default_tools_approval_mode, y cualquier herramienta puede sobrescribirlo con tools.<tool>.approval_mode. Los valores documentados son auto, prompt, writes y approve.

El interesante es writes. En palabras de OpenAI, «pregunta por las herramientas que no están marcadas como de solo lectura». Las búsquedas se ejecutan en silencio, todo lo demás se detiene y pregunta, y una herramienta sin ninguna anotación cuenta como escritura: el valor seguro cuando un servidor no dice nada. Además de los modos, la documentación de aprobaciones de Codex indica que las llamadas a herramientas MCP destructivas siempre requieren aprobación cuando la herramienta anuncia una anotación destructiva, salvo que también anuncie una anotación de lectura.

Un cambio que conviene conocer si tiene una configuración antigua: Codex ya no admite approval_policy = "untrusted", y ese ajuste retirado puede impedir que el cliente arranque. La confianza en un proyecto se fija ahora con el trust_level del proyecto.

ChatGPT en la web funciona con el mismo principio. En el modo desarrollador, disponible en las cuentas Pro, Plus, Business, Enterprise y Education, «las acciones de escritura requieren confirmación de forma predeterminada»; ChatGPT respeta readOnlyHint y trata cualquier herramienta sin ella como escritura. Una decisión puede recordarse por herramienta durante el resto de una conversación, y no más.

Claude Code y Claude Desktop: reglas que se escriben por nombre

Claude Code no lee las anotaciones para decidir. Usa reglas de permisos en tres listas —allow, ask y deny— evaluadas en un orden fijo: deny, luego ask, luego allow. Las herramientas MCP se llaman mcp__<server>__<tool>, así que mcp__notes__search permite una herramienta, mcp__notes__get_* permite una familia, y mcp__notes o mcp__notes__* cubre el servidor entero. El modo predeterminado se llama ahora Manual; los modos más permisivos incluyen acceptEdits, auto, en el que un clasificador revisa las acciones en lugar de usted, y bypassPermissions.

Dos detalles se inclinan hacia la seguridad. Los servidores del .mcp.json versionado de un proyecto necesitan su aprobación antes siquiera de conectarse. Y el autor de un servidor puede marcar una herramienta con _meta["anthropic/requiresUserInteraction"], tras lo cual Claude Code muestra su confirmación en cada llamada, incluso en acceptEdits, auto y bypassPermissions.

Los ajustes de conectores de Claude Desktop, en Customize → Connectors, agrupan las herramientas de un servidor en categorías como solo lectura y escritura/eliminación, y cada categoría o herramienta individual puede ponerse en Always allow, Needs approval o Blocked.

Cursor, VS Code, Zed y Devin Desktop: los editores

Cursor lo dice sin rodeos: «Cursor pide aprobación antes de usar herramientas MCP de forma predeterminada». MCP sigue los mismos Run Modes que los comandos de terminal. En Auto-review, las llamadas de la lista de permitidos se ejecutan al momento y todo lo demás pasa por un modelo clasificador; Run Everything ejecuta todas las llamadas a herramientas sin preguntar. La lista de permitidos acepta entradas server:tool con comodines. Una trampa: dejar vacía la lista de herramientas permitidas de un servidor permite todas las herramientas de ese servidor.

VS Code llama a su nivel predeterminado Manual permissions: todo lo que no esté aprobado automáticamente necesita confirmación. El diálogo permite aprobar un solo uso o conceder la aprobación para la sesión, el espacio de trabajo o todas las invocaciones futuras, y se pueden fijar aprobaciones por herramienta para cada servidor MCP. Allow all elimina por completo las confirmaciones, y Assisted permissions, en el que un modelo juzga cada llamada, figura como experimental. Una excepción merece atención: los servidores MCP que vienen dentro de un plugin de agente «se consideran de confianza implícitamente al instalar el plugin» y se saltan la confirmación de confianza aparte al arrancar. Instalar el plugin es la decisión de confianza.

Zed tiene el sistema de reglas más legible. agent.tool_permissions.default vale confirm salvo que lo cambie, con allow y deny como alternativas. Las reglas nombran las herramientas MCP como mcp:<server>:<tool_name> y pueden fijarse en permitir siempre, confirmar siempre o denegar siempre, y la denegación tiene prioridad. La propia confirmación ofrece «Allow once», «Deny once» y «Always for» la herramienta; para las herramientas MCP solo existe la opción a nivel de herramienta.

Devin Desktop, el antiguo Windsurf, cambió de modelo junto con el nombre. Su agente, Devin Local, «sustituye los niveles de ejecución automática por un sistema de permisos más detallado», y de forma predeterminada pregunta antes de llamar a cualquier herramienta MCP. Desde la confirmación se puede permitir una herramienta o todas las de ese servidor, para la sesión o de forma permanente, y las reglas Deny prevalecen sobre todo. Los administradores de Enterprise pueden aprobar de antemano servidores o herramientas concretos para toda la organización.

Lo que las anotaciones pueden y no pueden hacer

La especificación MCP da a los servidores un vocabulario para describir sus herramientas: readOnlyHint, destructiveHint, idempotentHint, openWorldHint. También dice a los clientes hasta qué punto creerlas: los clientes «DEBEN considerar las anotaciones de herramientas como no fiables salvo que provengan de servidores de confianza». Y pide un humano en el circuito con capacidad de denegar cualquier llamada a una herramienta.

Eso pone en perspectiva los dos diseños anteriores. Un cliente que decide por anotaciones, como el modo writes de Codex, es cómodo con un servidor de confianza: configura una línea, y cada nueva herramienta de escritura que añada el servidor pedirá confirmación automáticamente. Con un servidor en el que no confía, es exactamente tan seguro como honesto sea el servidor. Una herramienta que cambia datos y se declara de solo lectura se ejecuta sin preguntar.

Un cliente que le obliga a nombrar herramientas, como Claude Code o Zed, falla al revés. No le importa lo que afirme el servidor, pero una nueva herramienta de escritura añadida en una actualización solo queda cubierta si su regla era lo bastante amplia para abarcarla, o lo bastante estrecha para no incluirla y volver a preguntar. Las reglas por nombre son más seguras escritas como «permitir estas lecturas», no como «permitir este servidor».

Una configuración sensata para un servidor que lee y escribe

Sea cual sea el cliente, los mismos cuatro hábitos cubren la mayor parte del riesgo:

1. Permita las lecturas por nombre, no el servidor entero. Buscar y leer transcripciones es lo que un asistente hace todo el día; ahí es donde una confirmación cuesta más y protege menos.
2. Mantenga la confirmación en todo lo que comparte o reemplaza. Publicar para otras personas y sobrescribir texto son los dos tipos de cambio que no se deshacen volviendo a poner un valor.
3. Confíe en las anotaciones solo para servidores de confianza. Para un servidor de un registro que nunca ha usado, nombre sus herramientas en reglas.
4. Dé a un cliente menos fiable una instancia de solo lectura. Si el servidor admite un modo de solo lectura, un cliente puede limitarse a leer mientras otro conserva el acceso completo.

Señales de alarma: una entrada en la lista de permitidos de Cursor para un servidor con la lista de herramientas vacía, un plugin de VS Code que nadie del equipo revisó y «Always allow» pulsado en una herramienta cuyo nombre no leyó.

Cómo se ve esto en Speak-Y

El servidor MCP de Speak-Y está pensado para ambos tipos de cliente. Las herramientas de lectura —buscar grabaciones, leer transcripciones, resúmenes y tareas pendientes, listar etiquetas y canales— llevan readOnlyHint y leen la biblioteca directamente de su equipo. Las herramientas que cambian algo —etiquetas, títulos, nombres de hablantes, nueva transcripción, compartir en un canal del equipo— se declaran como modificadoras de datos y pasan por la aplicación Speak-Y en ejecución, donde cada llamada queda registrada y donde se pueden desactivar.

Dos de ellas están marcadas con destructiveHint a propósito: retranscribe, porque reemplaza el texto actual de una grabación, correcciones manuales incluidas, y share_to_channel, porque los compañeros pueden leer una grabación antes de que usted la retire. En el modo writes de Codex esas confirmaciones aparecen sin configurar nada; en Claude Code o Zed, permita las herramientas de lectura por nombre y deje el resto en ask.

Si prefiere que un cliente solo pueda leer, arranque el servidor con --read-only en la configuración de ese cliente: las herramientas que cambian datos no se le publican en absoluto, así que no hay nada que aprobar por accidente. La configuración está a un clic desde Configuración → Integraciones, y el servidor MCP es gratuito en todos los planes, incluido Free.

La confirmación de aprobación es solo uno de los controles que hacen seguro un asistente que escribe. Los demás —qué cambios son reversibles y qué conserva el registro— se tratan en qué hace seguro el acceso de escritura por MCP, y la documentación de MCP explica la configuración para cada cliente.

FAQ

¿Los clientes MCP preguntan antes de ejecutar una herramienta que cambia datos?

Todos los clientes importantes preguntan de forma predeterminada. Claude Code, Cursor, VS Code, Zed y Devin Desktop piden confirmación antes de ejecutar una herramienta MCP hasta que usted la aprueba de antemano, y el modo desarrollador de ChatGPT exige confirmación para toda herramienta que no esté marcada como de solo lectura. Lo que cambia es con qué precisión se puede aprobar de antemano después: por herramienta, por servidor, por sesión o para siempre. Comprobado el 29 de septiembre de 2026.

¿Qué clientes MCP usan la anotación readOnlyHint para decidir cuándo preguntar?

Codex y ChatGPT lo hacen de forma explícita. El modo de aprobación writes de Codex pregunta por las herramientas que no están marcadas como de solo lectura y siempre pregunta antes de una herramienta que se declara destructiva, y el modo desarrollador de ChatGPT trata cualquier herramienta sin readOnlyHint como una acción de escritura. Claude Code, Cursor, VS Code y Zed no documentan las anotaciones como criterio de aprobación; las reglas las escribe usted, por nombre de herramienta.

¿Puedo aprobar automáticamente las herramientas de lectura y que me sigan preguntando antes de escribir?

Sí, en todos los clientes de esta comparativa, aunque el mecanismo varía. En Claude Code, Zed, Cursor y Devin Desktop se permiten las herramientas de lectura por nombre, como mcp__server__search en Claude Code o mcp:server:search en Zed. En Codex el modo writes lo resuelve en una línea, confiando en que el servidor marque con honestidad sus herramientas de lectura.

¿Son las anotaciones de herramientas como readOnlyHint una garantía de seguridad?

No. La especificación MCP dice que los clientes deben considerar las anotaciones de herramientas como no fiables salvo que provengan de servidores de confianza. Un servidor que marca una herramienta de escritura como de solo lectura anula cualquier política del cliente basada en esa pista. Trate las anotaciones como una comodidad para los servidores en los que ya confía y nombre las herramientas de forma explícita en las reglas para los demás.

¿Cuál es la forma más segura de conectar un servidor de notas de reuniones a un asistente de IA?

Aprobar de antemano solo las herramientas de lectura, mantener la confirmación en todo lo que cambia datos y dar a los clientes en los que confía menos una instancia de solo lectura. Con Speak-Y, arrancar el servidor con --read-only en la configuración de un cliente elimina por completo las herramientas que cambian datos para ese cliente, mientras que otro cliente conserva el acceso completo con sus propias confirmaciones.