Cómo crear un servidor MCP en 30 minutos: paso a paso

Crear un servidor MCP significa escribir un pequeño servicio que, a través del Model Context Protocol, pone herramientas, recursos y prompts a disposición de clientes de IA como Claude. Eliges un SDK (Python o TypeScript), defines al menos una herramienta, eliges el transporte (stdio o Streamable HTTP) y registras el servidor en el cliente. El protocolo se basa en JSON-RPC 2.0 y el SDK se encarga por ti de todo el intercambio de mensajes. Tú solo escribes tu lógica de negocio.

Tres respuestas rápidas para empezar:

• Para el primer servidor funcional basta con un SDK, un entorno de ejecución (Python o Node.js) y una sola herramienta. Es realista conseguirlo en unos 30 minutos.
• En local desarrollas con el transporte stdio (sin puerto, sin autenticación); para servidores remotos usas Streamable HTTP con OAuth 2.1.
• MCP conecta agentes con herramientas y datos. De la colaboración entre agentes autónomos se encarga A2A, no MCP.

Qué es realmente un servidor MCP

Anthropic presentó el Model Context Protocol el 25 de noviembre de 2024 como estándar abierto para conectar aplicaciones de IA con sistemas externos: sistemas de archivos, bases de datos, software de gestión empresarial, herramientas para desarrolladores. Sus autores son David Soria Parra y Justin Spahr-Summers. Técnicamente, MCP es un protocolo JSON-RPC 2.0 sobre transportes intercambiables. En lugar de inventar un formato propio para cada integración de herramientas, cliente y servidor hablan el mismo idioma.

Un servidor MCP pone a disposición del cliente tres primitivas:

• Herramientas: funciones que el modelo puede invocar activamente (p. ej., «consultar el tiempo», «escribir un registro»). Son el componente más importante y más habitual.
• Recursos: fuentes de datos legibles que el cliente puede cargar en el contexto (archivos, contenidos de bases de datos, configuraciones).
• Prompts: plantillas predefinidas y parametrizables que el usuario puede invocar desde el cliente.

Para empezar, te centras exclusivamente en una herramienta. Los recursos y los prompts llegan más tarde.

Paso 1: elegir el transporte (stdio o HTTP)

La primera decisión de arquitectura tiene que ver con el transporte. MCP admite varias variantes; en la práctica, dos son relevantes.

Recomendación: empieza con stdio. El cliente inicia tu servidor como proceso local y se comunica a través de la entrada y la salida estándar. No hay puerto, ni configuración TLS, ni autenticación que resolver. En cuanto tu servidor tenga que ejecutarse en remoto, dar servicio a varios clientes o quedar detrás de un control de acceso, migras a Streamable HTTP.

Estado de la especificación: Streamable HTTP llegó con la revisión de la especificación del 26 de marzo de 2025 y sustituyó al anterior transporte HTTP+SSE. Esa misma revisión trajo la autorización OAuth 2.1, las anotaciones de herramientas y el batching de JSON-RPC. La revisión del 18 de junio de 2025 volvió a eliminar el batching. La revisión del 25 de noviembre de 2025 añadió, entre otras cosas, tareas experimentales para operaciones asíncronas, la elicitación basada en URL y los Client ID Metadata Documents para el registro de clientes. El funcionamiento sin estado, sin handshake de inicialización, y la llamada server/discover, con la que un servidor comunica sus versiones, capacidades e identidad, no llegaron hasta la revisión del 28 de julio de 2026.

Paso 2: elegir el SDK (Python o TypeScript)

Existen SDK oficiales para todos los grandes lenguajes de programación; los dos más usados son Python y TypeScript (más de 97 millones de descargas mensuales entre ambos, datos de 2026). La elección depende simplemente de tu stack actual:

• Python: ideal para equipos que trabajan cerca de datos/ML y para prototipos rápidos.
• TypeScript: ideal para equipos orientados a Node.js/Next.js y stacks web.

Ambos SDK se encargan del manejo de JSON-RPC, de la negociación de capacidades y de la conexión con el transporte. Tú declaras una herramienta con nombre, descripción y esquema de parámetros, y escribes la función propiamente dicha.

Paso 3: servidor mínimo con una herramienta (pseudocódigo)

El siguiente ejemplo en pseudocódigo muestra un servidor con una sola herramienta, que convierte importes entre divisas. La lógica es trivial a propósito: lo que importa es la estructura.

```

Pseudocódigo (inspirado en el estilo del SDK de Python)

server = MCPServer(name="fx-tools")

@server.tool(
name="convert_currency",
description="Convierte un importe de una divisa a otra. "
"Espera importe (número), origen (código ISO), destino (código ISO).",
input_schema={
"type": "object",
"properties": {
"importe": {"type": "number"},
"origen": {"type": "string"},
"destino": {"type": "string"}
},
"required": ["importe", "origen", "destino"]
}
)
def convert_currency(importe, origen, destino):
tipo = lookup_rate(origen, destino) # lógica de negocio propia
resultado = round(importe * tipo, 2)
return {"resultado": resultado, "tipo": tipo}

IMPORTANTE: logging SOLO en stderr, nunca en stdout (rompe JSON-RPC)

log_to_stderr("Iniciando servidor")

server.run(transport="stdio")
```

Aquí hay tres cosas decisivas que a menudo se pasan por alto:

1. La descripción no es decoración. El modelo decide únicamente a partir del nombre y la descripción si invoca la herramienta y cómo lo hace. Las descripciones vagas provocan llamadas erróneas o directamente ninguna llamada.
2. El input_schema (JSON Schema) define los parámetros de forma vinculante. Sin un esquema correcto, el cliente no puede validar los argumentos.
3. Con el transporte stdio, stdout está reservado para el protocolo. Todo el logging tiene que ir a stderr; si no, el flujo JSON-RPC se rompe.

Paso 4: registrar y probar el servidor en el cliente

Con stdio, registras el servidor indicándole al cliente el comando de inicio. En clientes como Claude Desktop se hace mediante un archivo de configuración que tiene más o menos esta forma:

```
{
"mcpServers": {
"fx-tools": {
"command": "python",
"args": ["ruta/a/server.py"]
}
}
}
```

Después de reiniciar el cliente, aparece tu herramienta. Pruébala en este orden:

1. Comprobar el descubrimiento: ¿aparece convert_currency en la lista de herramientas del cliente? Si no, lo que suele fallar es el arranque del subproceso (ruta incorrecta, dependencia que falta).
2. Provocar una llamada: haz una pregunta que active la herramienta («¿Cuánto son 500 EUR en CHF?»). El cliente debería invocar la herramienta con los argumentos correctos.
3. Comprobar la respuesta: ¿devuelve el servidor un resultado bien formado que el cliente integra en su respuesta?

Para depurar sin depender del modelo te ayuda el MCP Inspector oficial, una herramienta autónoma del proyecto MCP con la que puedes invocar herramientas directamente y seguir el protocolo JSON-RPC mensaje a mensaje. Eso acelera mucho la depuración.

Ejemplo concreto con cifras

Supongamos que conectas una lista de precios interna. El servidor ofrece la herramienta get_product_price. Un empleado pregunta en el cliente: «¿Cuánto cuesta el artículo A-204 en la variante L?». Sin MCP, el modelo tendría que adivinar o alucinar. Con la herramienta, el modelo llama a get_product_price(sku="A-204", variante="L"), el servidor devuelve {"preis": 49.90, "währung": "EUR", "lager": 12} y el modelo responde con datos reales. Todo el esfuerzo de implementación para una herramienta de solo lectura como esta cabe en un archivo y unas pocas docenas de líneas. La mayor parte de los 30 minutos mencionados al principio se va en conectar tu fuente de datos existente, no en el protocolo.

Errores frecuentes

• Logging en stdout: el error de principiante más común con el transporte stdio. Todo lo que no sea JSON-RPC tiene que ir a stderr.
• Descripciones de herramientas vagas: el modelo no invoca la herramienta o la invoca mal. Escribe las descripciones como si fueran la documentación de una API para un compañero.
• JSON Schema ausente o incorrecto: campos obligatorios sin marcar, tipos imprecisos. Así el cliente no puede validar los argumentos.
• Permisos demasiado amplios: una herramienta que puede hacer más de lo necesario es una superficie de ataque. El mínimo privilegio rige desde la primera línea.
• Brechas de seguridad por suposiciones de confianza: en 2025/2026 se han documentado, entre otros, la inyección indirecta de prompts a través de descripciones de herramientas, el envenenamiento de herramientas (Invariant Labs, PoC de WhatsApp de abril de 2025), el squatting con servidores look-alike, el Full-Schema Poisoning de CyberArk (cualquier parte del esquema de una herramienta puede ser un punto de inyección) y el «Toxic Agent Flow» a través de issues de GitHub manipulados. La causa es el modelo de confianza de MCP, optimista por principio, que equipara la corrección sintáctica con la seguridad semántica. La protección corre a cargo de quien opera el servidor: sandboxing, tokens con alcance limitado, OAuth 2.1 para los transportes HTTP y nada de instalar automáticamente servidores MCP desde registros no fiables.

Situación en 2026

En 2026, MCP es el estándar del sector, con amplio respaldo, para conectar agentes con herramientas: el 9 de diciembre de 2025, Anthropic transfirió el protocolo a la recién creada Agentic AI Foundation, bajo la Linux Foundation. La fundación la cofundaron Anthropic, Block y OpenAI, y el apoyo Platinum lo aportan AWS, Bloomberg, Cloudflare, Google y Microsoft. MCP es compatible, entre otros, con OpenAI (desde marzo de 2025), Google DeepMind (abril de 2025), Microsoft Copilot Studio, SAP Joule, Salesforce Agentforce, n8n y LangGraph. Claude dispone de un directorio con más de 75 conectores MCP oficiales. Para la colaboración entre agentes autónomos no apuestas por MCP, sino por A2A. La regla práctica es: MCP para capacidades, A2A para colaboración.

Para agencias y empresas B2B

Para las agencias, un servidor MCP propio es la vía directa para que capacidades propietarias (una función de investigación de palabras clave, un CMS interno, una API de precios) se puedan usar con cualquier proveedor, sin construir una integración específica para cada cliente de IA. Un servidor MCP bien construido una sola vez se reutiliza en distintas líneas de producto. Para quienes toman decisiones en B2B: si en 2026 usas agentes, vas a consumir o escribir servidores MCP, lo hayas planeado o no. Trata cada herramienta como relevante para permisos y auditoría. En Blck Alpaca diseñamos servidores MCP según el principio de mínimo privilegio, con esquemas limpios y registros de auditoría trazables. Escríbenos si quieres conectar una fuente de datos interna a tus agentes de IA conforme al RGPD.