La pregunta parece tener una respuesta por empresa, y no la tiene. En 2026 la línea divisoria pasa entre superficies, no entre fabricantes: la aplicación de escritorio de ChatGPT puede arrancar un servidor MCP en su máquina y ChatGPT en una pestaña del navegador no. Claude Code y Claude Desktop pueden los dos. Todos los editores de código con cliente MCP —Cursor, VS Code, Zed, Devin Desktop— pueden. Todo lo que se ejecuta en la nube de otro, por definición, no.
Esa distinción importa más de lo que parece. Un servidor local es un programa que su cliente lanza y con el que habla por la entrada y la salida estándar; no hay ningún puerto abierto, no se emite ninguna credencial y sus datos nunca salen de la máquina camino de las herramientas del asistente. Un servidor remoto es una URL, es decir, un operador, un token y una ruta de red. Elegir cliente es por tanto, en parte, elegir dónde tienen que estar sus datos para que un asistente pueda usarlos.
Esto es un repaso de quién admite qué, contrastado con la documentación de cada fabricante el 15 de agosto de 2026. Si el protocolo en sí le resulta nuevo, qué es un servidor MCP explica el vocabulario; si ya ha elegido cliente y solo necesita la ruta del archivo de configuración, configurar MCP en VS Code, Zed y Devin Desktop es la versión archivo por archivo.
| Cliente | stdio local | Remoto | Cómo lo pide |
|---|---|---|---|
| Claude Code | Sí | HTTP, SSE, WebSocket | Pregunta; los servidores del proyecto requieren aprobación previa |
| Claude Desktop | Sí | Sí | Aprobación explícita antes de cada acción |
| Aplicación de escritorio de ChatGPT | Sí | Sí | Cuatro modos de aprobación, compartidos con Codex |
| Codex CLI / extensión para el IDE | Sí | Sí | default_tools_approval_mode |
| ChatGPT en la web | No | Sí, solo HTTPS | A nivel de conector, según el plan |
| Cursor | Sí | SSE, Streamable HTTP | Pregunta por defecto; los Run Modes permiten listas de permitidos |
| VS Code | Sí | HTTP | Confiar una vez en el servidor y luego por invocación |
| Zed | Sí | Sí | Pregunta antes de cualquier acción de herramienta |
| Devin Desktop | Sí | Streamable HTTP, SSE | Pregunta por defecto; reglas por herramienta |
Una fila de esa tabla es la razón de ser de este artículo.
Busque esta pregunta y encontrará afirmaciones tajantes en las dos direcciones, a menudo en páginas actualizadas este mismo año. Ambas fueron ciertas en algún momento, y por eso siguen circulando.
El estado actual, según la documentación de OpenAI: «La aplicación de escritorio
de ChatGPT, Codex CLI y la extensión para el IDE admiten servidores MCP y
comparten la configuración MCP del mismo host de Codex». Esa configuración
compartida vive en ~/.codex/config.toml, o en un .codex/config.toml propio
del proyecto en proyectos de confianza, y admite explícitamente «servidores
STDIO: servidores que se ejecutan como un proceso local (arrancado por un
comando)».
Así que la aplicación de escritorio es un cliente MCP local. Configure un servidor una vez y lo verán los tres: la CLI, la extensión del editor y la aplicación de escritorio. No hay que darlo de alta tres veces.
ChatGPT en la web es otro producto con otra respuesta. Allí un conector personalizado es un servidor MCP remoto al que se llega por HTTPS mediante SSE o Streamable HTTP: usted pega una URL, no apunta a un comando. ChatGPT se ejecuta en la nube de OpenAI, así que solo puede alcanzar servidores expuestos a internet, y ejecutar uno local implica poner un túnel por delante. Los conectores personalizados dependen además del plan: están en Plus, Pro, Business, Enterprise y Edu, y no en Free ni en Go.
Ninguna de las dos mitades de la respuesta de internet es errónea. Son respuestas a preguntas distintas, y la pregunta que conviene hacerse es delante de qué ChatGPT está usted sentado.
Claude Code acepta servidores stdio con claude mcp add --transport stdio, y
remotos por HTTP, SSE —obsoleto en favor de HTTP— y WebSocket. La configuración
tiene tres ámbitos: local, de proyecto (.mcp.json, versionado) y de usuario
(~/.claude.json). Un .mcp.json versionado no se conecta en silencio: sus
servidores se quedan en «pendiente de aprobación» hasta que ejecute Claude de
forma interactiva en un espacio de trabajo de confianza y los apruebe, un valor
predeterminado sensato para un archivo que llega con un git clone.
Claude Desktop lee claude_desktop_config.json —en macOS en
~/Library/Application Support/Claude/, en Windows en %APPDATA%\Claude\— y
arranca cada servidor configurado al abrir la aplicación. El modelo documentado
es la aprobación por acción: «Todas las acciones requieren su aprobación
explícita antes de ejecutarse, lo que le garantiza el control total sobre lo que
Claude puede consultar y modificar». Las extensiones instaladas desde Settings →
Extensions son la versión empaquetada de lo mismo, y por eso la instalación con
un clic y el JSON escrito a mano acaban en el mismo sitio.
Cursor documenta tres transportes —stdio, SSE y Streamable HTTP— con
configuración de proyecto en .cursor/mcp.json y global en ~/.cursor/mcp.json.
Sobre el consentimiento es explícito: «Cursor pide aprobación antes de usar
herramientas MCP de forma predeterminada». La automatización es opcional y se
activa mediante los Run Modes, donde las herramientas MCP de la lista permitida
se ejecutan al instante en el modo Auto-review y todo lo demás pasa por un
clasificador.
VS Code admite tanto servidores HTTP remotos como servidores stdio locales,
configurados a nivel de espacio de trabajo en .vscode/mcp.json o a nivel de
usuario con el comando MCP: Open User Configuration. Añade un paso que los
demás no destacan: antes de que un servidor arranque por primera vez hay que
confirmar que se confía en él, con la opción de revisar su configuración desde
el propio diálogo. La confianza es una propiedad del servidor, no de cada
llamada.
Zed configura los servidores MCP desde Settings → AI → MCP Servers, con una
forma command/args/env para los locales y una forma url/headers para
los remotos. Sus permisos son los más finos del grupo:
agent.tool_permissions.default pide aprobación antes de ejecutar cualquier
acción de herramienta, incluidas las llamadas a herramientas MCP, y se pueden
escribir reglas individuales contra mcp:<server>:<tool_name>, de modo que
puede preaprobar la lectura y mantener la pregunta en todo lo que escribe.
Devin Desktop es el que cambió de nombre. Cognition renombró Windsurf como Devin Desktop el 2 de junio de 2026 mediante una actualización remota; los planes, las extensiones, los atajos de teclado y las conexiones MCP existentes se conservaron sin que el usuario tuviera que hacer nada, y el agente local Cascade fue sustituido por Devin Local, con Cascade descontinuado el 1 de julio de 2026. El soporte de MCP sobrevivió intacto: los servidores «se pueden configurar de dos maneras: como un comando local (transporte stdio) o como un servidor remoto (transporte HTTP)», con archivos de usuario, de proyecto y de sustitución local ignorada por git, y las herramientas MCP piden aprobación de forma predeterminada. Si sigue un tutorial antiguo de Windsurf, los consejos sobre el protocolo siguen valiendo: solo se han movido el nombre del producto y las rutas de los archivos.
Todos los clientes de esta comparativa preguntan de forma predeterminada. Esa es la buena noticia, y también es donde se esconde el detalle útil, porque preguntar en cada llamada es inservible y no preguntar nunca es inseguro. La pregunta de diseño interesante es qué hace un cliente entre ambos extremos.
Se usan tres mecanismos, y la mayoría de los clientes los combinan:
.mcp.json.writes de Codex «pregunta por las
herramientas que no están marcadas como de solo lectura»: buscar es
silencioso, cambiar no.mcp:<server>:<tool_name> en Zed y
tools.<tool>.approval_mode en Codex permiten decidir herramienta por
herramienta, el único mecanismo lo bastante preciso cuando un mismo servidor
ofrece los dos tipos.La asimetría es lo que conviene entender, porque depende de que el servidor sea honesto sobre cuáles de sus herramientas cambian cosas. Un servidor que declara todo como de solo lectura anula cualquier política del cliente por encima de él. Cuando conecta un servidor que no ha escrito usted, esa declaración forma parte de lo que está confiando: el mismo juicio del que trata qué hace seguro el acceso de escritura en MCP.
Los servidores locales no son automáticamente la mejor opción, y una comparativa que concluyera lo contrario estaría vendiendo algo.
Un servidor remoto es la forma adecuada cuando los datos no están en su máquina de entrada: un gestor de incidencias alojado, una API de pagos, un panel de monitorización. Poner un proceso local delante de un servicio en la nube añade un salto y no resuelve nada. Los servidores remotos funcionan además desde un navegador, desde un teléfono y desde el portátil de un compañero sin que nadie instale nada, y un solo operador puede corregir un fallo para todos a la vez. Si la restricción de su equipo es «tiene que funcionar para cincuenta personas sin permisos de administrador», ser solo remoto no es una limitación, es el requisito.
Los servidores locales ganan en un conjunto de casos más estrecho pero más nítido: los datos ya están en la máquina, son lo bastante sensibles como para preferir que no viajen, o no existe una versión alojada a la que conectarse. Las grabaciones de sus propias reuniones son las tres cosas a la vez.
El servidor MCP de Speak-Y es un proceso stdio local, y eso es lo que lo coloca en la columna izquierda de la tabla para todos los clientes que la tienen. Su asistente busca en las grabaciones y lee transcripciones, resúmenes y tareas pendientes directamente de la biblioteca que hay en su máquina, sin ningún relé en la nube por el camino y sin nada que tunelizar.
La separación entre lectura y escritura encaja con los mecanismos de cliente
descritos arriba. Leer no necesita nada más en ejecución. Los comandos que
cambian algo —etiquetas, títulos, nombres de interlocutores, retranscripción,
compartir en un canal de equipo— pasan por la aplicación Speak-Y en ejecución,
se declaran a su cliente MCP como comandos que modifican datos, de modo que
pregunta antes de ejecutarlos salvo que usted conceda un permiso permanente, y
quedan registrados en la aplicación, donde también se pueden desactivar. Si
prefiere que un asistente solo pueda leer, arrancar el servidor con
--read-only en la configuración de ese cliente hace que los comandos que
cambian cosas ni siquiera se le publiquen.
La instalación es de un clic desde Configuración → Integraciones, y es gratuita en todos los planes, incluido Free, algo que no es lo habitual entre los tomadores de notas de reuniones, donde MCP suele quedar detrás de un nivel de nube de pago.
Para ChatGPT en concreto, la consecuencia práctica de todo lo anterior es que la aplicación de escritorio es la superficie que hay que usar. Comparte la configuración de Codex, así que el servidor que añada para Codex CLI ya está ahí. La guía ChatGPT de escritorio y sus datos personales recorre esa instalación, y si está sopesando las dos formas de manera más general, MCP local frente a MCP en la nube trata de qué expone cada una y ante quién.
Depende de a qué ChatGPT se refiera. La aplicación de escritorio de ChatGPT sí puede: comparte la configuración MCP con Codex CLI y con la extensión para el IDE a través del mismo host de Codex, y esa configuración admite servidores STDIO arrancados por un comando en su máquina. ChatGPT en la web no puede: un conector web es un servidor MCP remoto al que se llega por HTTPS, así que un servidor local hay que exponerlo antes mediante un túnel. Comprobado el 15 de agosto de 2026.
Un servidor stdio local es un programa que el cliente arranca en su máquina y con el que habla por la entrada y la salida estándar. No queda ningún puerto de red a la escucha y ningún dato sale del ordenador para llegar hasta él. Un servidor remoto es un extremo HTTPS al que el cliente se conecta por internet, normalmente autenticado con un token, y sus peticiones viajan hasta quien lo opera.
Todos los clientes importantes lo piden de forma predeterminada, pero la granularidad varía. Cursor pide aprobación antes de usar herramientas MCP y ejecuta al instante las herramientas de la lista permitida en el modo Auto-review; Zed pregunta antes de cualquier acción de herramienta y admite reglas por herramienta como mcp:server:tool_name; Codex tiene cuatro modos de aprobación, de los cuales writes solo pregunta por las herramientas que no están marcadas como de solo lectura. Un servidor también puede marcar herramientas concretas como de solo lectura para que el cliente sepa cuáles son inofensivas.
No. Cognition renombró Windsurf como Devin Desktop el 2 de junio de 2026 mediante una actualización remota, y el agente local que antes se llamaba Cascade fue sustituido por Devin Local, con Cascade descontinuado el 1 de julio de 2026. Los planes, las extensiones, los atajos de teclado y las conexiones MCP existentes se conservaron sin que el usuario tuviera que hacer nada.
Todos los de esta comparativa capaces de ejecutar un servidor local, porque el servidor MCP de Speak-Y es un proceso local y no un servicio alojado: Claude Code, Claude Desktop, la aplicación de escritorio de ChatGPT y Codex, Cursor, VS Code, Zed y Devin Desktop. Es gratuito en todos los planes, incluido Free, y se instala con un clic desde Configuración → Integraciones.