Curso completo de MCP en producción: de tu portátil a un VPS

Hace unas semanas montamos un servidor MCP (Model Context Protocol) en Python. Funcionaba perfectamente. Y ese era exactamente el problema: funcionaba en mi portátil, dentro de mi carpeta, mientras Claude Code lo arrancaba como un proceso hijo. Cerraba Claude Code, cerraba el portátil o cambiaba de ordenador y todo desaparecía.

Eso no es un servidor. Es un script con un protocolo elegante.

Un servidor de verdad está funcionando antes de que llegues y seguirá funcionando después de que te vayas. Tiene una URL, está protegido, puede usarlo otro equipo y no depende de que tu ordenador personal siga encendido. Vamos a convertir ese MCP local en un servicio real desplegado en un VPS, administrado por Linux, expuesto con HTTPS y protegido mediante token.

Por qué tu servidor MCP local todavía no es un servidor

El proyecto original puede ser muy pequeño. En mi caso, todo el servidor vivía principalmente en un archivo server.py, con unas herramientas y dos recursos: uno para listar el catálogo de cursos y otro para consultar los detalles de un curso concreto a partir de su ruta.

La lógica no tiene nada de especial: el servidor lee un archivo JSON, expone información útil y Claude puede consultarla cuando necesita recomendar formación. Con unas 80 líneas de Python, ya tenemos herramientas y recursos funcionando.

Pero con transporte stdio, quien manda es el cliente. Claude Code inicia el proceso, se comunica con él a través de entrada y salida estándar, y cuando el cliente termina, el proceso muere con él.

Las consecuencias son bastante dolorosas:

• No puede usarlo una persona de tu equipo.
• No puedes conectarte desde otro ordenador o desde el móvil.
• No puedes integrarlo con un agente que viva en otra máquina.
• No puedes enseñarlo como una herramienta disponible de forma permanente.
• No existe fuera de tu entorno local.

La mayoría de tutoriales se detienen aquí, justo después del clásico “hola mundo”. Es comprensible, porque la parte de despliegue es menos glamurosa. Pero también es la que separa un juguete técnico de una herramienta que puede utilizar una empresa.

stdio vs HTTP: tres cosas que cambian por completo

Para sacar un servidor MCP de tu portátil, el primer paso es cambiar el transporte. Pasamos de stdio a HTTP, normalmente usando un servidor ASGI como Uvicorn.

1. El responsable deja de ser el cliente

Con stdio, el cliente es el propietario del proceso. Lo crea, lo controla y lo destruye. Con HTTP, el proceso vive en tu servidor y el cliente simplemente hace una petición a una URL.

Es un cambio conceptual importante: Claude Code deja de ser el dueño y pasa a ser un invitado autorizado para utilizar tu servicio.

2. La salida estándar vuelve a servir para los logs

En stdio, escribir un simple print puede romper el protocolo porque stdout es el canal de comunicación. Cuando trabajas con HTTP, esa limitación desaparece. HTTP se encarga del protocolo y stdout puede volver a utilizarse para registros, errores y diagnósticos.

Puede parecer un detalle menor, pero es una señal clara de que has entrado en el mundo de los servicios reales: procesos observables, logs persistentes y herramientas de administración.

3. Ganas alcance, pero también una superficie de ataque

Un servidor HTTP tiene una URL. Eso permite que otros clientes se conecten desde cualquier lugar, pero también significa que cualquiera que encuentre esa URL puede intentar hablar con él.

Al publicar un MCP en Internet ganas utilidad, sí. Pero también ganas responsabilidad. Por eso el dominio, HTTPS, el firewall y el token no son extras opcionales. Son parte del producto.

El código casi no cambia

La buena noticia es que las herramientas y recursos de MCP no tienen por qué cambiar. Tu lógica de negocio sigue siendo la misma. El catálogo, las funciones, los recursos y las respuestas permanecen intactos.

El cambio está en cómo arrancas la aplicación. En lugar de ejecutar el servidor mediante stdio, expones la aplicación MCP en un host y puerto concretos. De esta forma queda escuchando en una dirección HTTP y ya puede trasladarse a cualquier máquina.

En local, una prueba rápida puede ser arrancar el proceso y consultar la ruta MCP con curl. Si responde con un error de autorización, de hecho es una buena señal: significa que el proceso escucha correctamente y que la capa de protección está funcionando.

El servidor MCP solo es una pieza de un puzzle mucho más grande. Después vienen la memoria de los agentes, las cadenas de herramientas, la evaluación de resultados, el control del coste de tokens y el diseño de agentes que resuelvan problemas reales. Si quieres construir todo ese ecosistema paso a paso, tienes el curso de Ingeniería de Agentes de IA, con servidores MCP y el resto de piezas necesarias para llevarlos a producción.

Del portátil al VPS: un ordenador que no se apaga

Un VPS es, sin magia negra, un ordenador Linux accesible por SSH y encendido permanentemente. Es justo lo que necesita nuestro servidor MCP.

Para este despliegue usamos un VPS de Hostinger. La elección de recursos depende de la carga de tu aplicación. Para un MCP sencillo que consulta un catálogo o llama a unas cuantas herramientas, no necesitas una máquina gigantesca. Lo importante es contar con memoria suficiente, conectividad estable y una ubicación cercana para reducir la latencia.

Una vez creado el VPS, solo necesitas su IP y la contraseña inicial de administrador para entrar por SSH. Pero hay una norma que conviene cumplir desde el minuto uno: no ejecutes tu servidor MCP como root.

Crea un usuario sin privilegios para el servicio

Primero creamos un usuario específico, por ejemplo servermcp, le asignamos una contraseña y le damos acceso a sudo únicamente para las tareas necesarias de administración.

Esto no es una manía antigua. Si ejecutas un proceso Python como root, cualquier error de tu aplicación tendrá permisos de administrador. Un fallo en el código, una dependencia vulnerable o una mala configuración pueden convertirse en un problema mucho más serio de lo necesario.

Después actualizamos el sistema, instalamos UV, clonamos el repositorio y sincronizamos las dependencias. Un VPS no es diferente de tu portátil: sigue siendo una terminal Linux, solo que está a kilómetros de distancia y seguirá encendida cuando cierres la tapa del ordenador.

El código completo, incluidos los archivos de servicio y la configuración de Nginx, está disponible en el repositorio del servidor MCP.

systemd: la pieza que evita que tu MCP muera

Arrancar el servidor manualmente por SSH no basta. Si cierras la sesión, el proceso puede terminar. Si el VPS se reinicia, tu servicio no volverá por sí solo. Cambiaste de máquina, pero mantienes el mismo problema.

En Ubuntu y muchas distribuciones Linux, la solución es systemd. Le dices al sistema operativo: “este proceso es tuyo, arráncalo, mantenlo vivo y reinícialo si falla”.

Un archivo .service define principalmente:

• El usuario y grupo sin privilegios que ejecutarán el proceso.
• El directorio donde vive el repositorio MCP.
• El comando de inicio, normalmente con UV y Python.
• Las variables de entorno, incluido el token de acceso.
• La política Restart=always para relanzar el servicio si se cae.

El token debe ser largo y aleatorio. Puedes generarlo con OpenSSL y guardarlo como variable de entorno en el archivo del servicio, sin incluirlo directamente en el repositorio.

Después solo necesitas recargar systemd, activar el servicio para que arranque con el sistema, iniciarlo y comprobar su estado. La prueba de fuego consiste en reiniciar el VPS. Si, al volver a conectarte, el servicio continúa activo, ya tienes un MCP funcionando 24 horas al día, 7 días a la semana.

Y ahora sí puedes consultar logs sin destruir el protocolo. Con journalctl puedes seguir en directo los registros del servicio, investigar errores y comprobar que el proceso se reinicia como corresponde.

Dominio, HTTPS y token: las tres capas que no puedes saltarte

Hasta este punto, tu aplicación podría estar escuchando en un puerto HTTP. Publicarla así directamente trae tres problemas: una URL fea basada en una IP, tráfico sin cifrar y un servicio expuesto sin una puerta de entrada seria.

El orden correcto es sencillo: dominio, certificado y token.

Apunta un subdominio al VPS

En la zona DNS del dominio, crea un registro A que apunte un subdominio, por ejemplo mcp.tudominio.com, a la IP pública de tu VPS. La propagación puede tardar unos minutos, así que no te desesperes si no responde de inmediato.

Coloca Nginx delante de Python

Nginx actúa como proxy inverso. Recibe el tráfico público y lo redirige internamente hacia el proceso Python, que puede escuchar exclusivamente en 127.0.0.1.

Esta separación es importante. La aplicación Python deja de estar abierta directamente a Internet. Desde fuera solo se entra por Nginx, mediante los puertos web adecuados, mientras que el puerto interno del servidor MCP queda aislado.

Instala HTTPS con Certbot

Certbot permite solicitar e instalar un certificado TLS para Nginx. Cuando la configuración DNS es correcta y el puerto 80 está disponible, el resultado es una URL HTTPS con candado.

Esto no es estética. El token viajará en la cabecera de autorización y debe hacerlo cifrado. Sin HTTPS, alguien que intercepte el tráfico podría capturarlo.

Protege el acceso con Bearer Token

El middleware del servidor debe exigir una cabecera Authorization: Bearer con el token correcto para acceder a la ruta MCP. La ruta de salud puede quedar pública para verificar que el servicio está vivo, pero las herramientas y recursos deben exigir autorización.

La comprobación más importante es esta:

• Petición a la URL MCP sin token: respuesta 401 Unauthorized.
• Petición con el token correcto: respuesta 200.

Ese 401 no es un fallo. Es la barrera entre una herramienta privada y un servicio que cualquiera podría explotar. Hoy quizá tu MCP solo ofrece cursos. Mañana podría consultar clientes, bases de datos, calendarios o sistemas internos. No conviertas una URL encontrada por casualidad en un incidente de seguridad.

La prueba final: usar el MCP desde otro ordenador

La última prueba no consiste en que el servidor responda dentro del VPS. Consiste en configurarlo desde un segundo ordenador que no tenga el repositorio, ni Python, ni UV, ni el archivo JSON local.

Registras el servidor MCP remoto indicando la URL HTTPS, por ejemplo https://mcp.tudominio.com/mcp, y el token de autenticación. A partir de ahí, el cliente puede descubrir las herramientas y decidir por sí mismo cuándo utilizar el catálogo.

Ese es el momento en que todo cobra sentido: el agente necesita encontrar una recomendación, decide consultar el MCP, llama a la herramienta adecuada y responde utilizando datos que no viven en el ordenador desde el que se hace la consulta.

Tu portátil puede estar apagado, en reparación o guardado en una mochila. El VPS sigue haciendo su trabajo.

De script local a servicio real

El recorrido completo se resume en unos pocos pasos, aunque cada uno importa:

1. Cambiar el transporte MCP de stdio a HTTP.
2. Desplegar el proyecto en un VPS siempre disponible.
3. Ejecutarlo con un usuario sin privilegios.
4. Dejar que systemd lo arranque, reinicie y supervise.
5. Asignar un dominio fácil de recordar.
6. Configurar Nginx y un certificado HTTPS.
7. Cerrar el acceso directo al puerto de Python con firewall.
8. Exigir un token de acceso para cada petición.
9. Probarlo desde una máquina completamente distinta.

Y lo mejor es que no has tenido que reescribir la lógica de tus herramientas. El cambio está en la infraestructura que las rodea. Esa infraestructura puede parecer aburrida, pero es exactamente lo que hace que tu servidor sea útil, mantenible y seguro.

Si quieres seguir profundizando en inteligencia artificial, modelos de lenguaje y despliegue de herramientas para agentes, puedes explorar las rutas de formación en Inteligencia Artificial de Frogames Formación. Porque crear el primer servidor es solo el principio. El siguiente paso es construir agentes capaces de utilizarlo de verdad.