Las palabras local y nube se usan a propósito de los servidores MCP como si zanjaran la cuestión de la privacidad. No la zanjan. Responden con precisión a una sola pregunta — dónde se ejecuta el proceso del servidor — y dejan intacta la que de verdad importa a casi todo el mundo: quién acaba pudiendo leer sus datos.
En resumen: un servidor MCP local mantiene sus datos fuera de la infraestructura del proveedor; no los mantiene fuera de la conversación. Todo lo que su asistente lea a través de cualquier servidor MCP, local o en la nube, se envía al modelo con el que esté hablando. Local cambia quién almacena sus datos y quién puede alcanzarlos. No cambia lo que ve el modelo.
Este artículo separa esas dos cosas. Si el protocolo en sí le resulta nuevo, qué es un servidor MCP cubre antes lo básico.
La especificación MCP, revisión 2026-07-28, define exactamente dos transportes estándar, y encajan limpiamente con las dos palabras.
stdio, el local. El cliente arranca el servidor MCP como subproceso y ambos hablan por la entrada y la salida estándar de ese proceso, un mensaje JSON-RPC por línea. No hay conexión de red ni puerto. Cuando el cliente termina, cierra el flujo de entrada del servidor y el proceso se apaga. Eso es lo que significa en concreto «se ejecuta en su máquina».
Streamable HTTP, el de la nube. El servidor es un proceso independiente que
expone un único punto de acceso HTTP, y cada mensaje es un POST HTTP contra él.
El cliente lo alcanza por la red en una URL del tipo
https://mcp.example.com/mcp. Este es el transporte que hay detrás de cada
botón de «conectar su cuenta».
La distinción es una decisión de despliegue, no una diferencia de capacidades. La especificación es explícita: la semántica del protocolo es idéntica en todos los transportes; un transporte define cómo se enmarcan y se entregan los mensajes, no qué significan. Una herramienta que lee sus transcripciones de reuniones hace el mismo trabajo en ambos casos.
Esta es la pregunta que esas dos palabras suelen sustituir, y tiene más de dos respuestas. Cuatro partes pueden llegar a leer lo que circula por una conexión MCP.
| Quién | Servidor local (stdio) | Servidor en la nube (HTTPS) |
|---|---|---|
| El proveedor del servidor MCP | No recibe los datos | Los guarda y atiende cada petición |
| El proveedor de su modelo | Ve todo lo que lee el asistente | Ve todo lo que lee el asistente |
| Su aplicación de IA | Los lee en local para componer el prompt | Igual |
| Quien tenga el token | No hay ningún token que robar | Llega a los mismos datos hasta que se revoque |
La fila del medio es la que sorprende, y es la misma en las dos columnas. Un servidor MCP no le da al modelo un canal privado. Recupera texto y se lo entrega al cliente, que lo mete en el prompt. A partir de ahí los datos han salido de su máquina, se ejecutara el servidor donde se ejecutara.
La primera fila y la última son donde lo local gana de verdad. Con stdio no hay cuenta, ni copia guardada en el disco de otro, ni credencial que pueda robarse o filtrarse en una brecha, porque no hay nada que autorizar.
Aquí hay tres formas, no dos, y los proveedores rara vez separan la del medio.
Servidor en la nube, datos en la nube. El proveedor aloja el servidor, usted lo autoriza con OAuth en un navegador y su cliente hace una llamada HTTPS cuando necesita algo. Es la forma natural cuando sus datos ya viven en la nube de ese proveedor.
Proceso local, datos en la nube. El proveedor entrega un servidor que
ejecuta usted mismo: un comando npx, uvx o docker que arranca su cliente
de IA y que guarda una clave API. Nada de eso hace que los datos sean locales.
El proceso corre en su portátil y luego llama por red a la API del proveedor en
cada petición. Este es el caso que conviene descartar cuando alguien le dice que
su servidor MCP es local.
Proceso local, datos locales. Los datos ya están en la máquina, así que el servidor los lee sin ninguna llamada de red. Es la única forma en la que «local» describe los datos y no solo el proceso.
Lo que delata es la credencial, no el comando. Un inicio de sesión en el navegador significa que los datos son del proveedor y usted autoriza el acceso. Una clave API pegada en un archivo de configuración significa que un proceso local llama a su API en nombre de usted. Ninguna de las dos cosas es dato local.
Cuando pasa por una pantalla de OAuth para un servidor MCP en la nube, está emitiendo una credencial contra su cuenta, y conviene saber qué permite esa credencial.
La especificación MCP apoya esto en OAuth 2.1. Los clientes deben enviar el
parámetro resource de la
RFC 8707 para que el token quede
ligado a un servidor concreto, y los servidores deben validar que un token se
emitió para ellos y no aceptar ni reenviar ningún otro. Esa maquinaria existe
para impedir que un token emitido para un servicio se reutilice contra otro.
Tres consecuencias prácticas:
Nada de esto se aplica a stdio. La especificación de autorización dice explícitamente que cubre los transportes basados en HTTP y que las implementaciones que usan stdio no deben seguirla: han de tomar las credenciales del entorno.
Local no es sinónimo de seguro, y la versión honesta de este argumento tiene que decir qué se cede a cambio.
Normalmente no hay capa de permisos. Como la especificación de autorización no se aplica, un servidor stdio no suele tener noción de usuarios ni de scopes. Cualquier cosa que se ejecute con su cuenta de usuario puede, por lo general, arrancarlo y llamar a sus herramientas. En una máquina compartida o gestionada, eso importa.
Un servidor local escuchando en un puerto es otro animal. Algunos servidores
descritos como locales escuchan en realidad por HTTP. La especificación aborda
el caso directamente: los servidores deben validar la cabecera Origin para
prevenir ataques de DNS rebinding y, en uso local, deben enlazarse solo a
127.0.0.1 y no a 0.0.0.0. Sin esas protecciones, advierte, un atacante
podría usar DNS rebinding para interactuar con servidores MCP locales desde
sitios web remotos.
Hereda la cadena de suministro. Un servidor lanzado con npx descarga y
ejecuta código en su máquina con sus permisos. El
OWASP MCP Top 10, en beta a fecha
de 2026, incluye los ataques a la cadena de suministro y la manipulación de
dependencias (MCP04:2025) y el envenenamiento de herramientas (MCP03:2025) entre
sus diez categorías: riesgos que una instalación local trae consigo y un punto
de acceso alojado no. La especificación es tajante sobre el caso general: las herramientas
representan ejecución de código arbitrario, y las descripciones del
comportamiento de una herramienta deben considerarse no fiables salvo que
provengan de un servidor de confianza.
MCP no añade un modelo de permisos a sus datos. Estandariza cómo se describen y se llaman las herramientas; lo que una herramienta concreta puede tocar es una decisión que tomó quien escribió el servidor. De ahí se siguen dos cosas, sea cual sea el transporte:
Cuatro preguntas, respondibles desde la página de configuración de cualquier proveedor en un minuto aproximadamente.
https:// es un servidor en la
nube. Un comando npx, uvx o docker es un proceso en su máquina.Dicho sin rodeos, porque la elección no es de un solo lado:
La nube pierde en un solo eje, pero es el eje del que trata este artículo: una copia de sus datos está en la infraestructura de otro, alcanzable con una credencial.
Haga dos preguntas en lugar de una. Dónde se ejecuta el servidor le dice quién almacena sus datos y quién puede alcanzarlos con un token. Qué lee el asistente le dice qué llega al proveedor de su modelo, y esa respuesta es la misma en ambos casos.
Si la forma que quiere es proceso local sobre datos locales, eso es lo que hace
el servidor MCP de Speak-Y: forma parte de la aplicación de escritorio,
se instala desde Configuración → Integraciones en un clic y lee las
grabaciones que ya están en su máquina, sin cuenta, sin clave API y sin copia
alojada. La lectura funciona con la aplicación cerrada; las herramientas que
cambian algo pasan por la aplicación y piden confirmación, y la opción
--read-only limita un cliente a la lectura. El servidor es gratuito en todos
los planes. La documentación de MCP cubre la instalación manual, la
política de privacidad explica qué se guarda y dónde, y si quiere
ver cómo responden otras herramientas de notas a la misma pregunta, comparamos
sus servidores MCP uno al lado
del otro.
Un servidor local es un programa que su cliente de IA arranca en su propio ordenador y con el que habla por la entrada y la salida estándar del proceso, sin red de por medio. Uno en la nube es un servicio web que el cliente alcanza por HTTPS, autorizado con OAuth. La especificación MCP los llama transportes stdio y Streamable HTTP.
No. Un servidor local mantiene sus datos fuera de los servidores del proveedor, pero todo lo que el asistente lee a través de él se envía al proveedor de su modelo como parte de la conversación, igual que si lo hubiera pegado usted. Local controla el almacenamiento y el acceso, no lo que ve el modelo.
Es más privado, pero no automáticamente más seguro. La especificación de autorización de MCP se aplica solo a los transportes HTTP; a los servidores stdio se les indica que tomen las credenciales del entorno, así que un servidor local no suele tener capa de permisos propia. Cualquier cosa que se ejecute con su usuario puede alcanzarlo.
Mire las instrucciones de instalación. Una URL https:// y un inicio de sesión en el navegador significan la nube del proveedor. Un comando como npx, uvx o docker significa un proceso en su máquina. Un proceso local con una clave API sigue llamando a la API del proveedor, así que el comando por sí solo no dice dónde viven los datos.
Claude Desktop ejecuta servidores locales directamente, instalados como extensiones de escritorio. ChatGPT se conecta a puntos de acceso HTTPS remotos en modo desarrollador, así que un servidor stdio local hay que exponerlo antes mediante un túnel. El mismo servidor puede ser local en un cliente y remoto en otro.