Los servidores MCP locales se ejecutan como un proceso en tu propio equipo a través de stdio, mientras que los remotos están detrás de un endpoint HTTPS al que puede acceder cualquier persona de tu equipo. Este artículo compara configuración, seguridad, latencia, costo y escalabilidad para que elijas el servidor adecuado para tu agente de IA.
El archivo de configuración de tu agente de IA pide una cosa antes que nada: un command o un url. Esa sola línea decide dónde se ejecutan tus herramientas, quién puede acceder a ellas, qué pasa cuando tu equipo entra en suspensión y quién paga la máquina que hay detrás. Si eliges mal, acabarás vigilando un montón de procesos en segundo plano o dándole a un servidor ajeno una vía de acceso a tus archivos.
La elección entre un servidor MCP local y un servidor MCP remoto parece técnica, pero en realidad es una cuestión de confianza, distancia y propiedad. Este artículo explica cómo funciona cada uno, dónde gana cada uno, dónde falla cada uno, y termina con una lista breve para que decidas en cinco minutos y no en cinco reuniones.
💡 Respuesta corta: Usa un servidor local cuando la herramienta toque archivos, shells o datos privados de tu propio equipo. Usa un servidor remoto cuando varias personas, dispositivos o agentes necesiten la misma herramienta sin instalar nada.
El Model Context Protocol, o MCP, es un estándar abierto que permite a una aplicación de IA llamar a herramientas externas a través de una interfaz coherente. En lugar de escribir un plugin personalizado para cada modelo y cada aplicación, un desarrollador escribe un solo servidor. Cualquier cliente compatible puede entonces listar sus herramientas, llamarlas y leer los resultados.
Intervienen tres roles. El host es la aplicación que usas, como un editor de código o un asistente de chat. Dentro de él vive un cliente MCP, que mantiene una conexión uno a uno con un servidor. El servidor expone herramientas (acciones que el modelo puede solicitar), recursos (datos que el modelo puede leer) y prompts (plantillas reutilizables). Los mensajes viajan como JSON-RPC 2.0, así que el tráfico es texto estructurado y simple, sin importar cómo llegue del punto A al punto B.
Esa parte de "cómo llega del punto A al punto B" es todo el debate entre local y remoto.
La especificación define dos transportes estándar:
Los servidores locales casi siempre usan stdio. Los remotos usan Streamable HTTP, que sustituyó al antiguo transporte HTTP más SSE. Las herramientas en sí pueden ser idénticas en ambos casos. Solo cambia la infraestructura de conexión, y esa infraestructura es lo que determina tu modelo de seguridad, tu latencia y tu factura de mantenimiento.
Con stdio, tu cliente lee un archivo de configuración, lanza el comando que escribiste y mantiene ese proceso activo durante toda la sesión. Las peticiones entran por stdin, las respuestas salen por stdout y los registros van a stderr. Si escribes un print suelto en stdout, corrompes el flujo del protocolo, un error clásico del primer día.
{
"mcpServers": {
"project-files": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-filesystem", "/Users/me/projects"]
}
}
}
No hay puerto que abrir, ni regla de cortafuegos, ni pantalla de inicio de sesión. El proceso hereda tus permisos de usuario y tus variables de entorno, y eso es exactamente lo que lo hace tan cómodo y lo que merece que lo pienses bien.
Cada compañero de equipo tiene que instalar el entorno de ejecución, fijar la versión correcta y copiar la configuración. Actualizas el servidor y diez equipos se desincronizan. Además, cada aplicación cliente lanza su propio proceso, así que tres editores significan tres copias ejecutándose a la vez. Y un servidor local muere con tu sesión, así que nada puede llamarlo mientras tu equipo está cerrado.
El soporte es el costo oculto. Cuando una herramienta falla en el equipo de una persona, te toca depurar una versión de Node, un problema de PATH o un paquete de Python que falta, en lugar de la herramienta en sí.
Un servidor remoto vive en una URL como https://tools.example.com/mcp. El cliente envía los mensajes JSON-RPC como peticiones HTTP POST a ese único endpoint. El servidor responde con una respuesta JSON normal, o abre un stream de Server-Sent Events cuando tiene actualizaciones de progreso o varios mensajes que enviar. Una cabecera de sesión permite que el servidor mantenga el estado entre llamadas.
Añadirlo requiere un solo comando en la mayoría de los clientes:
claude mcp add --transport http notes https://tools.example.com/mcp
Como el endpoint es accesible desde internet, la autenticación pasa de "quién ha iniciado sesión en este equipo" a "quién tiene un token válido". El flujo de autorización de la especificación se basa en OAuth, así que el usuario inicia sesión desde el navegador y el cliente guarda un token con permisos limitados y revocable.
El conector propio de PicassoIA es un buen ejemplo real. Es un servidor MCP remoto que expone herramientas para la generación de imágenes, la edición de imágenes y la generación de video. Los trabajos son asíncronos: una llamada de generación devuelve de inmediato un ID de predicción, y el cliente consulta el resultado con sondeos. Un límite compartido de cinco predicciones simultáneas por cuenta se aplica a todas las conexiones, algo que solo es posible porque el estado vive en el servidor. Tu equipo nunca necesita una GPU, una descarga de modelos ni un entorno de Python.
Ahora dependes del tiempo de actividad de otro y de tu propia conexión. Los viajes de ida y vuelta por la red añaden latencia a cada llamada a una herramienta, y un handshake lento puede hacer que un agente parezca lento. Lo que el servidor necesite de tu equipo, como un archivo local, simplemente no está ahí. Alojarlo implica certificados TLS, monitorización, límites de uso y alguien de guardia. Y un endpoint público es un objetivo, así que necesita autenticación adecuada desde el primer día.
| Factor | Local (stdio) | Remoto (Streamable HTTP) |
|---|---|---|
| Dónde se ejecuta | En tu equipo, como proceso hijo | Un servidor alojado detrás de una URL |
| Configuración por usuario | Instalar un entorno de ejecución y editar la configuración | Pegar una URL e iniciar sesión |
| Actualizaciones | Manuales en cada equipo | Se despliegan una sola vez |
| Necesita red | No | Sí |
| Acceso a archivos locales | Directo | Ninguno, a menos que los subas |
| Modelo de autenticación | Usuario del sistema operativo y variables de entorno | OAuth o tokens de portador |
| Compatibilidad con varios usuarios | Limitada | Pensado para ello |
| Sobrecarga de latencia | Insignificante | Un viaje de ida y vuelta por la red en cada llamada |
| Costo de ejecución | Tu propio hardware | Alojamiento más mantenimiento |
| Fallo típico | El proceso se cae o no arranca | Caída, tiempo de espera agotado o token caducado |
Ninguna de las dos opciones es automáticamente más segura. Un servidor local se ejecuta con tus permisos, así que un paquete malicioso o con errores puede leer tus archivos y tu configuración SSH, y cualquier cosa que se incorpore mediante npx o uvx es código que probablemente no has auditado. Un servidor remoto mantiene ese código fuera de tu equipo, pero ahora confías a su operador todo lo que recibe la herramienta, y cada petición viaja por la red.
💡 Regla general: Trata cualquier servidor MCP como si fuera una extensión del navegador. Comprueba quién lo escribió, fija la versión y concede los permisos más restrictivos que aún le permitan funcionar.
Hay algunos detalles específicos que vale la pena hacer:
127.0.0.1 y valida la cabecera Origin; de lo contrario, una página web en tu navegador puede acceder a ellos mediante DNS rebinding.La capa de stdio casi no cuesta nada. Una llamada remota añade al menos un viaje de ida y vuelta por la red, que puede ser de unos pocos milisegundos dentro de una misma región y de unos cientos entre continentes, además de TLS y cualquier comprobación de autenticación. En la práctica, el trabajo propio de la herramienta, como una consulta a una base de datos, una llamada a una API o un render de imagen, eclipsa al transporte. La latencia remota solo se nota con agentes muy habladores que lanzan decenas de llamadas pequeñas seguidas.
La fiabilidad funciona al revés. Un proceso local falla de forma ruidosa y visible, normalmente al arrancar. Un servicio remoto puede fallar en silencio: un token caducado, un límite de uso, una caída regional. Planifica reintentos y escribe mensajes de error que un modelo pueda interpretar y usar.
Establece tiempos de espera explícitos en ambos lados. Un cliente que espera indefinidamente una llamada remota colgada congela toda la conversación, mientras que un servidor que se rinde demasiado pronto corta trabajos largos legítimos, como el render de video. Informa del progreso de cualquier tarea que dure más de unos pocos segundos.
Lo local no cuesta nada alojar, pero cuesta tiempo darle soporte, y cada ticket de "en mi equipo funciona" te llega a ti. Lo remoto cuesta dinero y trabajo operativo, pero ahorra tiempo de soporte en cuanto interviene un equipo. El punto de equilibrio está en el momento en que más de un puñado de personas necesita el mismo servidor.
Una forma sencilla de calcularlo: cuenta las personas, multiplica los minutos que cada una dedica al mes a la configuración y la resolución de problemas, y compara ese número con un plan de alojamiento pequeño. Para dos personas, la ruta local suele ganar. Para veinte, rara vez.
Elige lo local cuando tus herramientas toquen tus propias cosas: un repositorio de código, una carpeta de notas, una base de datos local o un navegador que automatizas. Lo local también es el mejor hogar para los prototipos, porque puedes editar el servidor y reiniciarlo en segundos, sin un pipeline de despliegue.
Elige lo remoto cuando la herramienta pertenezca al equipo: sistemas de tickets, bases de conocimiento internas, recursos de diseño compartidos, datos de facturación. La autenticación centralizada y los registros de auditoría importan más que ganar unos pocos milisegundos. Lo remoto también es la única opción cuando el cliente no puede lanzar procesos, algo que ocurre con la mayoría de los asistentes web y las aplicaciones móviles.
Despliégalo por etapas. Empieza con un servidor remoto de solo lectura para que la gente lo pruebe sin riesgo, añade herramientas de escritura cuando el registro de auditoría se vea sano, y mantén un interruptor de emergencia que revoque los tokens de un solo paso. Los equipos que se saltan este orden suelen enterarse de sus errores por un mensaje furioso y no por un panel de control.
Responde a estas preguntas en orden y detente en el primer "sí":
Los proyectos reales rara vez eligen solo una opción. Estos patrones aparecen una y otra vez:
El modelo híbrido da sus frutos cuando trabajas desde una cafetería con una conexión inestable. Las herramientas de archivos siguen funcionando en local mientras las herramientas alojadas reintentan en segundo plano, y nada sensible sale de tu equipo a menos que tú decidas que debe salir.
/Users/me/notes no tiene sentido en una máquina en la nube. Si los datos están en tu equipo, el servidor debe estar en tu equipo.Elijas el transporte que elijas, la recompensa es la misma: un asistente de IA que hace trabajo real por ti en lugar de solo hablar de él. Una conexión remota es la forma más rápida de notarlo, porque no hay nada que instalar ni nada que mantener en marcha.
Pruébalo primero con imágenes. PicassoIA Image convierte un prompt en lenguaje natural en una imagen terminada en segundos, con siete relaciones de aspecto, una semilla que puedes bloquear y sin límite por imagen. Escribe un prompt, genera algunas variaciones y luego cambia un solo detalle, como el objetivo, la luz o el ángulo de la cámara, y observa qué cambia. Ese pequeño ciclo de prompt, resultado y ajuste es el hábito que hace que cualquier herramienta posterior, MCP o no, sea más fácil de usar.
Si escribes o revisas código de servidor tú mismo, un buen modelo de programación te ayudará. Claude Sonnet 5, GPT 5.6 Sol, Gemini 3.5 Flash y Kimi K2.6 están disponibles en PicassoIA, así que puedes comparar cómo maneja cada uno el mismo esquema de herramienta.
¿Listo para experimentar? Abre PicassoIA, elige un modelo de la lista completa de modelos y genera tu primera imagen hoy mismo.
Elige tu idioma
