Un servidor MCP remoto ofrece herramientas a clientes de IA mediante HTTP, en lugar de hacerlo a través de un proceso local. Para alojarlo, empaqueta el servidor en un contenedor, ejecútalo en un VPS detrás de HTTPS y exige autenticación antes de permitir que un cliente llame a una herramienta. El transporte actual es Streamable HTTP y un servidor pequeño funciona sin problemas en un VPS modesto.
¿Qué es un servidor MCP remoto y en qué se diferencia de uno local?
Model Context Protocol (MCP) es un protocolo abierto basado en JSON-RPC que permite a una aplicación de IA descubrir y llamar herramientas expuestas por un servidor independiente. El lugar donde se ejecuta el servidor distingue ambos tipos. Un servidor MCP local usa el transporte stdio: el cliente lo inicia como subproceso y se comunica con él mediante la entrada y salida estándar. Por eso, solo ese cliente puede usarlo en esa máquina. Un servidor MCP remoto es un proceso independiente detrás de un único endpoint HTTP, como https://mcp.example.com/mcp. Cualquier cliente que pueda acceder a la URL y presentar credenciales válidas puede llamarlo.
El transporte remoto se llama Streamable HTTP. Sustituyó al antiguo transporte HTTP+SSE, que la especificación considera obsoleto desde la versión 2025-03-26 del protocolo y desaconseja para nuevas implementaciones. La revisión actual, 2026-07-28, lo simplificó aún más: cada mensaje JSON-RPC usa su propio POST y desaparecieron el stream GET independiente y las sesiones a nivel de protocolo. Los clientes se actualizan a ritmos distintos, así que usa un SDK compatible con ambas etapas. El SDK de Python que aparece más adelante cumple este requisito.
Los equipos alojan sus propios servidores por tres motivos: compartir un conjunto de herramientas, mantener un endpoint siempre activo que no dependa de la laptop de alguien y conservar los datos privados en infraestructura bajo su control.
| Aspecto | Local (stdio) | Remoto (Streamable HTTP) |
| Dónde se ejecuta | Subproceso iniciado por el cliente en la misma máquina | Proceso independiente en un servidor, detrás de un endpoint HTTP |
| Quién puede acceder | Solo el cliente que lo inició | Cualquier cliente que pueda acceder a la URL y autenticarse |
| Autenticación | Ninguna a nivel de protocolo; las credenciales provienen del entorno | Encabezado Authorization en cada solicitud; flujo basado en OAuth según la especificación |
| Uso habitual | Herramientas personales que necesitan archivos o procesos locales | Herramientas compartidas por equipos, integraciones siempre activas y servicios de datos privados |
| Principal desventaja | Es sencillo, pero queda ligado a una máquina y un usuario | Todos pueden acceder, así que debes encargarte de HTTPS, autenticación, logs y actualizaciones |
Requisitos para alojar un servidor MCP: ¿qué tamaño de VPS necesitas?
La mayoría de los servidores MCP son capas ligeras sobre una API, por lo que la capa MCP consume pocos recursos. Tus herramientas determinan el tamaño necesario. Para alojar un servidor MCP, calcula los recursos según la herramienta más exigente, comienza con poco y revisa el uso real con docker stats antes de ampliar el VPS.
| Tipo de servidor | Qué determina el uso de recursos | Punto de partida |
| Wrapper de API | Un proceso de Python o Node que reenvía llamadas a otras API | 1 vCPU, 1-2 GB de RAM |
| Con base de datos | Las consultas y la propia base de datos, si la ejecutas en el mismo VPS | 2 vCPU, 4 GB de RAM o más |
| Navegador o ejecutor de código | Instancias de navegadores headless o código aislado, cada uno con su propio consumo de memoria | 4 vCPU, 8 GB de RAM o más |
Varios servidores pequeños pueden compartir un VPS detrás de un solo proxy inverso. En ese caso, un plan con bastante RAM resulta conveniente.
Crea un servidor MCP mínimo que puedas desplegar
Este ejemplo usa el SDK oficial de Python, el paquete mcp, en su versión 2.3.0 al momento de escribir este artículo. Si sigues tutoriales antiguos, considera que FastMCP pasó a llamarse MCPServer en la versión 2.x y la ruta de importación anterior ya no funciona. El siguiente servidor tiene una herramienta, un endpoint de estado y el transporte Streamable HTTP. Lee su hostname público desde una variable de entorno porque el SDK solo responde solicitudes dirigidas a hosts autorizados. Cualquier otro host recibe 421 Misdirected Request. Esta medida protege contra ataques de DNS rebinding.
# server.py
import os
from mcp.server import MCPServer
from mcp.server.transport_security import TransportSecuritySettings
from starlette.requests import Request
from starlette.responses import JSONResponse
mcp = MCPServer("word-tools")
@mcp.tool()
def word_count(text: str) -> int:
"""Count the words in a piece of text."""
return len(text.split())
@mcp.custom_route("/health", methods=["GET"])
async def health(request: Request) -> JSONResponse:
return JSONResponse({"status": "ok"})
if __name__ == "__main__":
host = os.environ["MCP_PUBLIC_HOST"]
mcp.run(
transport="streamable-http",
host="0.0.0.0",
port=8000,
stateless_http=True,
transport_security=TransportSecuritySettings(
allowed_hosts=[host, f"{host}:*"]
),
)
Hay tres detalles relevantes. El endpoint MCP predeterminado es /mcp. La opción stateless_http elimina el seguimiento de sesiones, por lo que no necesitas sticky sessions si ejecutas más de una copia. Además, el SDK nunca autentica rutas personalizadas como /health, así que no devuelvas información confidencial desde ellas.
Despliega el servidor MCP con Docker en un VPS
Primero instala Docker. La guía para instalar Docker en Ubuntu explica el proceso paso a paso. Después, coloca un Dockerfile y un archivo de Compose junto a server.py. El contenedor se ejecuta con un usuario distinto de root, se reinicia automáticamente y publica su puerto solo en 127.0.0.1. Así, únicamente puede acceder un proxy ubicado en el mismo host.
# Dockerfile
FROM python:3.13-slim
RUN pip install --no-cache-dir "mcp==2.3.0"
RUN useradd --create-home --uid 10001 mcp
USER mcp
WORKDIR /app
COPY --chown=mcp:mcp server.py .
EXPOSE 8000
CMD ["python", "server.py"]
# docker-compose.yml
services:
mcp:
build: .
restart: unless-stopped
environment:
MCP_PUBLIC_HOST: mcp.example.com
ports:
- "127.0.0.1:8000:8000"
healthcheck:
test: ["CMD", "python", "-c", "import urllib.request; urllib.request.urlopen('http://127.0.0.1:8000/health')"]
interval: 30s
timeout: 5s
retries: 3
docker compose up -d --build
docker compose ps
curl -i http://127.0.0.1:8000/health
El último comando debe devolver 200 junto con {«status»:»ok»}. Sustituye mcp.example.com por un hostname cuyo registro DNS apunte a tu VPS.
Protege tu servidor MCP remoto: HTTPS, autenticación y límites
Un endpoint MCP abierto permite que cualquiera que encuentre la URL ejecute tus herramientas, así que nunca lo dejes sin protección. Estos pasos agregan HTTPS, una comprobación de bearer token y límites básicos.
- Abre únicamente los puertos 80, 443 y SSH. La guía del firewall UFW muestra los comandos. Caddy necesita los puertos 80 y 443 para generar certificados automáticamente. El registro DNS A o AAAA debe apuntar previamente al servidor.
- Crea un token con openssl rand -hex 32 y guárdalo en un archivo .env junto a docker-compose.yml como MCP_TOKEN=<value>. No incluyas ese archivo en el control de versiones.
- Agrega Caddy como segundo servicio mediante el Caddyfile y el bloque de servicio que aparecen más adelante. Caddy termina HTTPS, obtiene certificados de Let’s Encrypt o ZeroSSL por su cuenta y rechaza las solicitudes sin el encabezado Authorization correcto.
- Haz una prueba desde el exterior: una solicitud sin token o con un token incorrecto debe devolver 401. Después, agrega el servidor a un cliente y configura el token.
- Limita las herramientas. Expón solo las necesarias, separa las herramientas de lectura y escritura en servidores con tokens distintos y aplica límites de solicitudes por token a las herramientas costosas o destructivas.
# Caddyfile (in ./caddy/)
mcp.example.com {
@no_token not header Authorization "Bearer {$MCP_TOKEN}"
respond @no_token "Unauthorized" 401
reverse_proxy 127.0.0.1:8000
}
# add under services: in docker-compose.yml
caddy:
image: caddy:2.11
restart: unless-stopped
network_mode: host
env_file: .env
volumes:
- ./caddy:/etc/caddy
- caddy_data:/data
# add at the top level of docker-compose.yml
volumes:
caddy_data:
Si ya ejecutas Nginx Proxy Manager, puedes aplicar el mismo método con un proxy host y una comprobación de encabezado. Monta la configuración de Caddy como directorio y conserva /data para que los certificados sobrevivan a los reinicios.
Este bearer token compartido funciona como barrera de acceso, pero no es el modelo de autorización de la especificación MCP. La autorización es opcional según la especificación, aunque para transportes HTTP se espera un flujo basado en OAuth 2.1. Tu servidor actúa únicamente como resource server, publica OAuth Protected Resource Metadata (RFC 9728), toma el access token del encabezado Authorization en cada solicitud, nunca del query string, y rechaza tokens que no se hayan emitido para él. El SDK de Python admite este esquema mediante un verificador de tokens y un servidor de autorización que los emite. Un token estático no incluye una identidad por usuario ni fecha de vencimiento. Rótalo manualmente y considera plenamente confiable a cualquiera que lo tenga. Cambia a OAuth cuando cada persona necesite permisos distintos o cuando un cliente solo sea compatible con OAuth.
La autenticación no detiene la inyección de prompts. Controla quién puede llamar a tus herramientas, pero no lo que un modelo hace con el texto que devuelven. Si una herramienta obtiene una página web, un correo o un ticket, las instrucciones ocultas en ese contenido pueden dirigir a un agente que también tenga herramientas con capacidad de escritura. La especificación propone varias capas: los servidores deben validar entradas, aplicar controles de acceso, limitar solicitudes y sanear salidas. Los clientes deben permitir que una persona rechace llamadas a herramientas. Asigna los privilegios mínimos, evita combinar herramientas de datos privados con otras que leen contenido no confiable o envían datos al exterior y registra las llamadas. Estas medidas limitan el daño, pero no garantizan que un servidor sea seguro. La lista de seguridad para VPS cubre la protección del host.
Conecta Claude, Cursor y otros clientes a tu servidor MCP
Cada cliente que aparece a continuación permite agregar un servidor remoto mediante una URL. Usa el endpoint completo y envía el token como encabezado.
- Claude Code: ejecuta claude mcp add –transport http con un nombre, la URL y una opción –header. Su documentación indica que el transporte SSE está obsoleto.
- Cursor: agrega una entrada url y headers a .cursor/mcp.json para el proyecto o a ~/.cursor/mcp.json para todos los proyectos. Cursor admite Streamable HTTP y puede leer el token desde una variable de entorno.
- VS Code: agrega un servidor de tipo http a .vscode/mcp.json. VS Code intenta usar primero Streamable HTTP y recurre a SSE si no funciona. Un prompt de inputs evita guardar el token en el archivo.
- Claude (claude.ai, Desktop y celular): agrega un conector personalizado en Customize > Connectors con la URL HTTPS. La conexión se realiza desde la nube de Anthropic, por lo que el servidor debe estar disponible públicamente. Las opciones de inicio de sesión son OAuth o ninguna. Los encabezados fijos de solicitudes están disponibles en beta para un grupo limitado de organizaciones.
claude mcp add –transport http word-tools https://mcp.example.com/mcp \
–header «Authorization: Bearer $MCP_TOKEN»
// .cursor/mcp.json
{
"mcpServers": {
"word-tools": {
"url": "https://mcp.example.com/mcp",
"headers": { "Authorization": "Bearer ${env:MCP_TOKEN}" }
}
}
}
// .vscode/mcp.json
{
"inputs": [
{ "type": "promptString", "id": "mcp-token", "description": "MCP token", "password": true }
],
"servers": {
"word-tools": {
"type": "http",
"url": "https://mcp.example.com/mcp",
"headers": { "Authorization": "Bearer ${input:mcp-token}" }
}
}
}
Si falla una conexión, comprueba primero lo siguiente:
- 401 en todas las solicitudes: falta el encabezado, no incluye el prefijo Bearer o no coincide con MCP_TOKEN en .env.
- 421 Invalid Host header: el hostname del cliente no aparece en allowed_hosts. Corrige MCP_PUBLIC_HOST y vuelve a compilar.
- Errores de certificado: el DNS debe apuntar al VPS y los puertos 80 y 443 deben estar accesibles para que Caddy pueda emitir el certificado.
- Bloqueos o desconexiones: usa la URL /mcp y no una URL /sse. Claude interpreta las URL terminadas en /sse como el transporte anterior. Comprueba también que ningún proxy almacene en búfer las respuestas transmitidas.
Monitorea, registra y actualiza un servidor MCP autoalojado
Un servidor MCP autoalojado puede fallar sin avisar: el agente simplemente deja de usar la herramienta.
- Logs: registra el nombre de la herramienta, la marca de tiempo, la duración, qué token se usó y cada respuesta 401 del proxy. Nunca registres argumentos completos ni tokens. La especificación advierte que los tokens guardados en los logs de un servidor pueden ser robados. Consulta la salida del contenedor con docker compose logs -f mcp.
- Alertas: el healthcheck del contenedor cubre la app. Un monitor externo para el endpoint HTTPS cubre el DNS, los certificados y el proxy. La guía de Uptime Kuma explica las alertas de uptime, mientras que la guía de Prometheus y Grafana agrega métricas.
- Actualizaciones: fija las versiones, vuelve a compilar con docker compose build –pull y después ejecuta docker compose up -d. Conserva la imagen anterior para hacer rollback y lee el changelog del SDK antes de instalar una versión principal nueva, ya que la versión 2.x cambió el nombre de FastMCP.
Por qué alojar servidores MCP en un VPS de Contabo
Un servidor MCP remoto necesita una máquina siempre activa y un costo predecible. En la línea Core disponible en Contabo, la ventaja es la cantidad de RAM por euro. Por eso, un Cloud VPS con 8 GB de RAM o más puede alojar varios servidores MCP pequeños detrás de una instancia de Caddy y aún dejar espacio para una base de datos. El precio mensual es fijo, algo conveniente para un servicio que funciona todo el día. Si la ubicación de los datos afecta a tus herramientas privadas, revisa las ubicaciones disponibles de los centros de datos durante el proceso de compra.
Según la publicación sobre el lanzamiento del firewall, todos los VPS y VDS incluyen uno. Esto agrega una segunda capa de filtrado delante del firewall del host. Para calcular recursos destinados a otras cargas además de MCP, consulta la guía de especificaciones de VPS para agentes de IA. Si tus herramientas llaman a un modelo local, la publicación sobre el lanzamiento de GPU VPS describe ese hardware. Los nombres de los planes y sus precios pueden cambiar, así que confírmalos en las páginas actuales de Contabo antes de hacer tu pedido.
Preguntas frecuentes sobre servidores MCP remotos
¿Qué es un servidor MCP remoto?
Un servidor MCP remoto es un servidor de Model Context Protocol que se ejecuta en un host de red y atiende a clientes de IA mediante HTTP con el transporte Streamable HTTP. A diferencia de un servidor stdio local, varios clientes pueden acceder a él mediante una URL, por lo que necesita HTTPS y autenticación.
¿Necesito un VPS para alojar un servidor MCP?
No, puedes ejecutarlo en una laptop o una plataforma serverless. Un VPS es adecuado si buscas un endpoint siempre activo, un costo mensual fijo y control sobre tus datos. Un servidor pequeño que funciona como wrapper de API necesita muy poca RAM, así que incluso un VPS básico puede servir.
¿Cómo protejo un servidor MCP remoto?
Sírvelo mediante HTTPS, exige un encabezado Authorization en cada solicitud, vincula el contenedor a localhost detrás de un proxy inverso y expón solo las herramientas necesarias. Usa el flujo basado en OAuth de la especificación para configuraciones multiusuario. Estas medidas no eliminan el riesgo de inyección de prompts, así que asigna los privilegios mínimos a las herramientas.
¿Puedo ejecutar un servidor MCP en Docker?
Sí. Un servidor MCP es un proceso normal, por lo que funciona bien en un contenedor. Usa una imagen base ligera, un usuario distinto de root, una política de reinicio y un healthcheck. Publica el puerto en 127.0.0.1 para que solo pueda acceder tu proxy inverso.
¿Cuál es la diferencia entre los servidores MCP locales y remotos?
Un servidor MCP local se ejecuta como subproceso de un cliente y se comunica mediante stdio, así que solo ese cliente puede usarlo. Un servidor MCP remoto se ejecuta de forma independiente detrás de un endpoint HTTP con Streamable HTTP. Varios clientes pueden compartirlo, lo que requiere HTTPS, autenticación y monitoreo.
Aviso: Las especificaciones, funciones y precios de los productos mencionados en este artículo pueden cambiar y variar según la región, el periodo de facturación y las promociones vigentes. Consulta el sitio web oficial de cada proveedor o marca para conocer las cifras, los precios y los tipos de cambio actuales en tu moneda local.