Servidor MCP remoto o local: stdio, Streamable HTTP y cuál conviene a tu equipo

Los dos transportes que define la especificación MCP

El Model Context Protocol codifica cada mensaje como JSON-RPC. La especificación (revisión 2025-11-25) define exactamente dos transportes estándar para llevar esos mensajes, y dice que los clientes deberían soportar el primero siempre que sea posible:

1. stdio. El cliente lanza el servidor como subproceso. El servidor lee mensajes JSON-RPC de la entrada estándar y los escribe en la salida estándar, uno por línea. Puede registrar logs en la salida de error, y no debe escribir nada más en stdout.
2. Streamable HTTP. El servidor es un proceso independiente en un único endpoint HTTP, como https://example.com/mcp, que acepta POST y GET. Cada mensaje del cliente es un POST. El servidor responde con un único objeto JSON o abriendo un flujo de Server-Sent Events cuando tiene varios mensajes que enviar. Sustituyó al antiguo transporte HTTP+SSE de la revisión 2024-11-05, hoy obsoleto.

"Local" y "remoto" son los nombres cotidianos de esos dos. Un servidor local es casi siempre stdio; un servidor remoto es siempre Streamable HTTP. Puedes correr un servidor Streamable HTTP en localhost, y la especificación indica que esos servidores deberían escuchar solo en 127.0.0.1, pero las formas comunes son las dos anteriores. La sección de transportes de la especificación tiene las reglas completas; la entrada del glosario sobre servidores remotos es la versión corta.

Cómo funciona un servidor local

Instalas algo, normalmente un programa pequeño en Node, Python o Go, y lo añades a la configuración de tu app de IA con el comando para ejecutarlo. Cuando la app arranca, lanza el proceso. El servidor suele leer una clave de API o una ruta de base de datos del entorno que la app le pasa. Cuando cierras la app, el proceso muere.

Esta es la forma original de MCP, y sigue siendo la correcta para una gran clase de servidores:

• Un servidor de sistema de archivos que lee las carpetas que le indicas.
• Un servidor de base de datos con una cadena de conexión guardada en tu perfil de shell.
• Un envoltorio sobre una herramienta de línea de comandos ya instalada en tu máquina.
• Cualquier cosa que estés prototipando en una tarde.

Sus fuerzas son la simplicidad y la localidad. No hay red, ni certificado TLS, ni inicio de sesión, ni multi-tenencia: el servidor sirve a una persona, la que lo lanzó. La especificación dice que los servidores stdio no deberían usar el flujo de autorización OAuth y que deberían tomar las credenciales del entorno.

Sus debilidades son los mismos hechos vistos desde el lado del equipo. Cada persona instala y actualiza su propia copia. Cada copia necesita su propia clave. Una clave en un archivo de configuración en un portátil es una clave que puede copiarse, subirse por accidente a un repositorio o quedarse atrás cuando alguien se va. Y nada central sabe quién llamó a qué.

Cómo funciona un servidor remoto

Un servidor remoto es un servicio web. Lo añades a tu app por URL. En la primera llamada el servidor responde 401 Unauthorized con un puntero a sus metadatos; la app descubre el servidor de autorización, abre un navegador, inicias sesión y apruebas un conjunto de scopes, y desde entonces cada petición lleva un token bearer en la cabecera Authorization. El cliente MCP dentro de la app se encarga de todo ese baile; la persona solo ve una pantalla de consentimiento.

Streamable HTTP añade algunos mecanismos que notarás como usuario u operador:

• Sesiones. Un servidor puede devolver una cabecera MCP-Session-Id en la inicialización, y el cliente debe enviarla en cada petición posterior. El servidor puede terminar la sesión en cualquier momento, tras lo cual el cliente inicia una nueva.
• Streaming. Para una llamada larga a una herramienta, el servidor puede abrir un flujo SSE, enviar notificaciones de progreso y terminar con la respuesta. Si la conexión se corta, el cliente puede reconectar con Last-Event-ID y el servidor puede reenviar lo perdido.
• Validación de Origin. Los servidores deben validar la cabecera Origin en cada conexión y rechazar las incorrectas con 403, para impedir que una página web maliciosa hable con un servidor a través del navegador.
• Autenticación en cada llamada. El token va en la cabecera de cada petición, nunca en la URL, y el servidor debe comprobar que fue emitido para este servidor en concreto.

La recompensa es que un despliegue sirve a todos. Nadie instala nada. El acceso se concede por persona, limitado a lo que aprobó y revocable desde el servidor. Cada llamada puede auditarse contra la persona detrás del token.

El coste es que ahora operas un servicio: hosting, TLS, disponibilidad, límites de tasa, aislamiento de tenants y un servidor de autorización OAuth o una integración con uno. Para un servidor que solo usas tú, es mucha maquinaria.

Servidor MCP remoto y local, lado a lado

¿Cuál deberías usar?

Hazte tres preguntas.

¿De quién son los datos? Si el servidor lee tus propios archivos o una base de datos que solo tú tocas, local. Si lee un sistema que comparten varias personas, con registros que pertenecen a la empresa y permisos distintos por persona, remoto. Un servidor local no tiene forma de expresar "Priya puede ver el valor de los deals y Tom no"; corre con la clave que le dieron.

¿Quién tiene que instalarlo? Si la respuesta es "yo, una vez", local está bien. Si la respuesta es "cada compañero, y mantenerlo actualizado", un servidor remoto elimina toda esa tarea. Hemos visto fallar la versión local de esto en menos de una semana: la configuración de una persona tiene una clave vieja, la de otra tiene una ruta que solo funciona en su máquina.

¿Qué pasa cuando alguien se va? Con un servidor local, su clave vive en un archivo que no puedes ver. Con un servidor remoto respaldado por OAuth, revocar su cuenta termina todos los tokens que creó, en la siguiente llamada.

Una regla razonable para un equipo pequeño: servidores locales para las herramientas de desarrollo en el portátil de cada persona; servidores remotos para cada producto en el que el equipo trabaja de verdad.

Cuándo un equipo debería alojar su propio servidor remoto

La mayoría de equipos se conectarán a servidores remotos que operan los proveedores. A veces tiene sentido alojar uno: un sistema interno sin proveedor, una base de datos que quieres que los asistentes consulten con permisos por persona, o una API que construiste. Antes de hacerlo, presupuesta las partes que no son las herramientas en sí:

1. Un servidor de autorización. La especificación de autorización de MCP espera OAuth 2.1 con PKCE y descubrimiento de metadatos. Puedes operar uno o poner delante del servidor un proveedor de identidad que lo soporte.
2. Validación del token en cada petición, incluida la comprobación de que el token se emitió para tu servidor y no para otro recurso.
3. Aislamiento de tenants. El token de una petición debe acotar lo que puede ver. Construye el servidor de modo que se cree una instancia nueva, o un contexto nuevo, por petición alrededor de ese token, y que nada se cachee entre personas.
4. Límites de tasa y auditoría. Un cliente ocupado no debería dejar sin recursos a los demás, y querrás saber después quién ejecutó qué herramienta.
5. Operación. TLS, disponibilidad, versionar la lista de herramientas sin romper a los clientes.

Si esa lista parece pesada para lo que necesitas, mantén el servidor local, o espera al proveedor.

Por qué Atrix es solo remoto

Nuestro propio servidor MCP es un ejemplo práctico de la elección. Atrix es un espacio de trabajo compartido: los proyectos, documentos, clientes, calendario y registros de personas de un equipo viven en él, y lo que cada persona puede ver es distinto. Un servidor local tendría que correr con una clave tan poderosa como la persona que la creó, en cada portátil, y el servidor nunca sabría quién estaba preguntando en realidad.

Así que el servidor de Atrix es un único endpoint remoto, https://atrix.dev/api/mcp, por Streamable HTTP. No hay paquete que instalar. En Claude Code toda la configuración es una línea, claude mcp add --transport http atrix https://atrix.dev/api/mcp, seguida de /mcp y Authenticate; se abre el navegador, eliges un espacio de trabajo y apruebas scopes, y el cliente guarda un token de acceso de corta vida con un token de refresco rotativo. El servidor construye una instancia nueva por petición alrededor del token presentado, así que nada se comparte entre peticiones ni espacios de trabajo, y cada llamada se audita por herramienta, resultado y sujeto. Expone 85 herramientas y está listado en el Registro oficial de MCP y en Glama. La página de la función explica qué hacen las herramientas.

Los límites son reales. No hay modo sin conexión ni forma de usarlo sin una cuenta de Atrix. Los límites de tasa son 120 llamadas y 30 escrituras por minuto por token. Y como los scopes solo pueden estrechar lo que una persona ya puede hacer, un asistente conectado a través de la cuenta de alguien nunca puede ver más que esa persona; si necesitas un servidor que llegue a todo, no es este, y creemos que es la elección correcta.

Preguntas frecuentes

¿Qué diferencia hay entre un servidor MCP remoto y uno local?

Un servidor local corre en tu máquina como subproceso y habla por stdio, con credenciales del entorno. Un servidor remoto corre en una URL HTTPS por Streamable HTTP, autentica a cada persona con OAuth y sirve a muchos usuarios desde un único despliegue.

¿Es mejor stdio o Streamable HTTP?

Ninguno es mejor en general. La especificación define ambos y pide a los clientes que soporten stdio siempre que sea posible. stdio es más simple y no tiene exposición en red; Streamable HTTP es la única opción cuando el servidor es compartido o está alojado fuera de la máquina del usuario.

¿Puedo correr un servidor Streamable HTTP en local?

Sí. La especificación dice que los servidores HTTP que corren en local deberían escuchar solo en localhost y deben validar la cabecera Origin para evitar DNS rebinding. Sigue siendo una forma menos común que stdio para un servidor de un solo usuario.

¿Los servidores MCP remotos necesitan OAuth?

La especificación de autorización de MCP dice que las implementaciones con transporte HTTP deberían seguirla, y se basa en OAuth 2.1. Algunos servidores aceptan un token bearer pegado a mano, que es más simple y más débil: el token es de larga vida, vive en un archivo de configuración y no está acotado por una pantalla de consentimiento.

¿Qué pasó con el transporte HTTP+SSE?

Se definió en la revisión 2024-11-05 y fue sustituido por Streamable HTTP en la 2025-03-26. La especificación actual lo marca como obsoleto y describe cómo clientes y servidores pueden mantener compatibilidad con la forma antigua.

¿El servidor MCP de Atrix está disponible en local?

No. Es solo remoto, en https://atrix.dev/api/mcp, porque los datos del espacio de trabajo son compartidos y los permisos por persona deben aplicarse en el servidor en cada llamada.

Siguiente paso

Si vas a conectar un asistente a Atrix, la guía para desarrolladores tiene los pasos exactos para Claude Code, Claude Desktop, ChatGPT y Cursor, y la página de MCP lista las herramientas. Si estás decidiendo cómo construir tu propio servidor, lee antes las entradas sobre cliente MCP y servidor MCP remoto.