KDnuggets muestra cómo montar un servidor MCP stateless en Python con acceso por HTTP

KDnuggets publicó el 9 de octubre de 2026 una guía paso a paso titulada «Build Your First MCP Server in Python (Stateless Spec Edition)». El texto explica cómo escribir un servidor MCP en Python y exponer por HTTP los tres primitivos de Model Context Protocol: herramientas (tools), recursos (resources) y prompts. El énfasis recae en la palabra stateless: el servidor no guarda la sesión entre llamadas. El anuncio es breve, así que los detalles de la edición de la especificación habrá que contrastarlos con la documentación oficial. Aun así, la dirección está clara: el protocolo con el que se conectan los agentes a sistemas externos se vuelve más sencillo de operar.

Por qué el estado es el mayor problema

MCP nació como una forma unificada de conectar a un modelo de lenguaje funciones y datos externos. Las primeras implementaciones se apoyaban en stdio y en conexiones de larga duración. Para un prototipo local resulta cómodo. En producción aparecen los problemas: hay que almacenar la sesión en algún sitio, las solicitudes deben enrutarse a la misma instancia, el escalado horizontal se complica y las plataformas serverless llevan mal las conexiones largas.

El enfoque stateless elimina estas restricciones. Cada solicitud HTTP es autosuficiente: llega, se procesa y recibe respuesta. El servidor puede ponerse detrás de un balanceador convencional, ejecutarse en varias réplicas y reiniciarse sin perder contexto. Si aun así hace falta conservar estado, este vive en un almacenamiento externo, no en la memoria del proceso.

Qué contiene la guía

El material está pensado para quienes construyen su primer servidor MCP. Según lo indicado en el anuncio:

• Lenguaje: Python
• Transporte: HTTP
• Primitivos: 3 (tools, resources, prompts)
• Modo: stateless, sin sesiones entre solicitudes
• Fuente y fecha: KDnuggets, 9 de octubre de 2026

Los primitivos cumplen funciones distintas, y confundirlos al diseñar el servidor sale caro. Las tools son funciones que el propio modelo invoca: búsqueda, consulta a una API, escritura en una base de datos. Los resources son datos direccionables mediante URI: archivos, documentos, filas de tablas. Los prompts son plantillas de instrucciones predefinidas que normalmente elige el usuario o la aplicación cliente.

Llama la atención que la guía opte por HTTP en lugar de un proceso local. Un servidor así es accesible para varios clientes y equipos, se puede proteger con autenticación y se monitoriza como cualquier otro servicio de red.

Cómo aplicarlo en la práctica

Lo más recomendable es empezar poco a poco. Cree una sola herramienta con una firma y una descripción claras: el modelo elige las funciones precisamente por su descripción, y un texto vago acaba en llamadas erróneas. Después añada un recurso y un prompt para ver los tres primitivos en funcionamiento. Pruebe el servidor con un depurador como MCP Inspector antes de conectarlo a un agente real.

Antes de pasar a producción conviene revisar tres cosas. Primera: la versión de la especificación y la del SDK. La «edición stateless» implica que parte de los ejemplos antiguos puede comportarse de otra manera. Segunda: dónde se guarda todo lo que antes vivía en la sesión. Los carritos, los tokens y los resultados intermedios deben trasladarse a Redis o a una base de datos. Tercera: la autenticación y la limitación de permisos de las herramientas. Un servidor que puede escribir en una base de datos no debe estar abierto a todo internet.

Para los equipos que construyen agentes, la guía sirve como punto de partida. No sustituye a la especificación, pero ofrece un esqueleto funcional mínimo desde el que avanzar hacia integraciones propias.