Construir un servidor MCP propio
Índice de contenidos
- Puntos clave
- ¿Qué es el Model Context Protocol y por qué construir tu propio servidor?
- ¿Qué exponen las herramientas, los recursos y los prompts?
- ¿Cómo se escribe un servidor MCP mínimo con el SDK de Python?
- ¿Cómo conectas el servidor a Claude, Cline o Goose?
- ¿Cuándo usar el transporte stdio y cuándo HTTP?
- Preguntas frecuentes
- ¿En qué se diferencia esto de instalar un servidor MCP ya hecho?
- ¿Necesito FastMCP o el SDK de bajo nivel?
- ¿Es seguro exponer herramientas a un modelo?
- Conclusión
- Fuentes
Un servidor MCP propio expone tus datos y funciones a cualquier asistente de IA mediante el Model Context Protocol. Con el SDK oficial de Python y su clase FastMCP escribes un servidor en unas veinte líneas: defines herramientas, recursos y prompts como funciones anotadas con tipos, y lo conectas a Claude, Cline o Goose por stdio o HTTP.
Un servidor MCP es la pieza que conecta tus datos y tus funciones con cualquier asistente de IA que hable el Model Context Protocol. En esta guía construyes uno desde cero con el SDK oficial de Python: instalas el paquete, escribes un servidor mínimo con FastMCP, expones herramientas, recursos y prompts, y lo enchufas a Claude, Cline o Goose mediante los transportes stdio y HTTP. No es lo mismo que instalar un servidor MCP ya hecho: aquí escribes el tuyo. La misma explicación está disponible en inglés.
Puntos clave
- El Model Context Protocol (MCP) es un protocolo abierto que Anthropic presentó en noviembre de 2024 para conectar modelos de lenguaje con datos y herramientas externas mediante mensajes JSON-RPC[1] 2.0.
- Un servidor MCP expone tres tipos de capacidad: herramientas (funciones que el modelo ejecuta), recursos (datos de solo lectura) y prompts (plantillas reutilizables).
- El SDK oficial de Python se instala con
pip install "mcp[cli]"; la versión estable es la 1.28.1 (junio de 2026) y requiere Python 3.10 o superior. - Con la clase FastMCP las anotaciones de tipo son el esquema: no escribes JSON Schema ni código de validación, solo funciones decoradas con
@mcp.tool(),@mcp.resource()y@mcp.prompt(). - Un servidor se comunica por stdio (proceso local) o por Streamable HTTP (remoto), y se registra en el asistente con una pequeña configuración JSON.
¿Qué es el Model Context Protocol y por qué construir tu propio servidor?
El Model Context Protocol es un estándar abierto que define cómo una aplicación de IA (el host) se comunica con servicios externos que le aportan contexto y capacidades. La documentación oficial lo describe como "una forma estandarizada de conectar los LLM con el contexto que necesitan". La idea toma prestada la filosofía del Language Server Protocol de los editores de código: en lugar de que cada asistente escriba una integración distinta para cada herramienta, todos hablan el mismo protocolo sobre JSON-RPC 2.0.
En esa arquitectura hay tres papeles. El host es la aplicación con el modelo (Claude, un editor con Cline, un agente hecho con el SDK de Anthropic). El cliente vive dentro del host y mantiene una conexión con cada servidor. El servidor es lo que tú construyes: un proceso que ofrece datos y acciones concretas, por ejemplo consultar tu base de datos interna, leer un repositorio o llamar a una API de tu empresa. Construir el tuyo tiene sentido cuando ningún servidor público cubre tu caso: quieres exponer un sistema propietario, aplicar tus propias reglas de acceso o mantener los datos dentro de tu red.
¿Qué exponen las herramientas, los recursos y los prompts?
Un servidor MCP ofrece al cliente hasta tres primitivas, y conviene entender la diferencia porque el modelo las trata de forma distinta:
- Herramientas (tools): funciones que el modelo decide invocar para actuar. Reciben argumentos, ejecutan código y devuelven un resultado. Son el equivalente a la llamada a funciones, pero portables entre asistentes. Requieren aprobación del usuario antes de ejecutarse.
- Recursos (resources): datos de solo lectura que el host puede cargar en el contexto, identificados por una URI (por ejemplo
archivo://informe.txt). Se parecen a peticiones GET: aportan información, no ejecutan efectos secundarios. - Prompts: plantillas de mensajes reutilizables que el usuario invoca de forma explícita, útiles para flujos repetidos como "resume este documento con este formato".
La regla práctica es sencilla: si algo cambia el mundo o llama a una API, es una herramienta; si solo aporta información, es un recurso; si es un texto guía que el usuario lanza a mano, es un prompt. El cliente puede además ofrecer capacidades al servidor (muestreo, roots y elicitación), pero para un primer servidor te bastan las tres primitivas del lado servidor.
¿Cómo se escribe un servidor MCP mínimo con el SDK de Python?
Empieza por instalar el SDK oficial. El extra [cli] añade el comando mcp, que trae el inspector de desarrollo:
pip install "mcp[cli]"
Si usas el gestor de paquetes uv, el equivalente es uv add "mcp[cli]". Con el SDK listo, crea un archivo servidor.py. Este servidor de ejemplo expone una herramienta que consulta una temperatura y un recurso con la lista de ciudades disponibles:
from mcp.server.fastmcp import FastMCP
mcp = FastMCP("meteo")
@mcp.tool()
def temperatura(ciudad: str) -> str:
"""Devuelve la temperatura actual de una ciudad."""
datos = {"Madrid": 21, "Sevilla": 28, "Bilbao": 17}
return f"{datos.get(ciudad, 15)} grados en {ciudad}"
@mcp.resource("ciudades://lista")
def ciudades() -> str:
"""Lista de ciudades con datos disponibles."""
return "Madrid, Sevilla, Bilbao"
if __name__ == "__main__":
mcp.run(transport="stdio")
Fíjate en lo que no has escrito. No hay JSON Schema, no hay análisis de la petición ni código de validación: las anotaciones de tipo (ciudad: str) son el esquema, y la cadena de documentación de la función se convierte en la descripción que ve el modelo. Esa es la ventaja de FastMCP, la interfaz de alto nivel del SDK. Antes de conectarlo a un asistente, pruébalo con el inspector, que abre una interfaz web para invocar tus herramientas a mano:
mcp dev servidor.py
¿Cómo conectas el servidor a Claude, Cline o Goose?
Un asistente lanza tu servidor como un proceso hijo y se comunica con él por su entrada y salida estándar. Para registrarlo, añades una entrada al archivo de configuración del host indicando qué comando ejecutar. En Claude Desktop es claude_desktop_config.json; en Cline dentro de VS Code es cline_mcp_settings.json; y Goose usa su propio archivo de extensiones. La forma es la misma en los tres:
{
"mcpServers": {
"meteo": {
"command": "python",
"args": ["/ruta/absoluta/servidor.py"]
}
}
}
Usa siempre la ruta absoluta al archivo y, si trabajas con un entorno virtual, apunta command al Python de ese entorno para que las dependencias estén disponibles. Al reiniciar el asistente, este arranca tu servidor, negocia capacidades y descubre tus herramientas y recursos. A partir de ahí el modelo puede pedir la temperatura de Bilbao, y el usuario aprueba la ejecución antes de que ocurra. Con Claude Code el registro es aún más directo: el comando claude mcp add añade el servidor sin editar el JSON a mano.
¿Cuándo usar el transporte stdio y cuándo HTTP?
MCP define dos transportes. El de stdio es el que has usado: el host lanza el servidor como subproceso local y hablan por tuberías. Es la opción por defecto para servidores que corren en la misma máquina que el asistente, sin puertos ni autenticación de red. El de Streamable HTTP sirve el servidor por la red y sustituyó al antiguo transporte HTTP+SSE; es lo que necesitas si el servidor vive en otro host o lo comparten varios usuarios. Cambiar de uno a otro es una sola línea:
if __name__ == "__main__":
mcp.run(transport="streamable-http")
Con HTTP, FastMCP publica el servidor en http://localhost:8000/mcp por defecto. Ten en cuenta que exponer un servidor por la red implica añadir autenticación y control de acceso: un servidor MCP ejecuta código y accede a datos, así que trata cada herramienta como una superficie de ataque y exige consentimiento explícito del usuario antes de cada acción, tal como recomienda la especificación. La revisión más reciente del protocolo es la del 25 de noviembre de 2025, y el SDK de Python acumula unas 23.600 estrellas en GitHub, señal de un ecosistema ya maduro.
Preguntas frecuentes
¿En qué se diferencia esto de instalar un servidor MCP ya hecho?
En que aquí escribes el servidor tú. Instalar un servidor MCP existente consiste en descargar un proceso que otra persona programó (para GitHub, Slack o tu sistema de archivos) y registrarlo en tu editor. Construir el tuyo es la opción cuando ningún servidor público expone lo que necesitas: un sistema interno, una API privada o unas reglas de acceso propias. El SDK de Python te permite pasar de la idea a un servidor funcional en unas veinte líneas.
¿Necesito FastMCP o el SDK de bajo nivel?
Para casi todo, FastMCP. Es la interfaz de alto nivel del SDK oficial y resuelve el esquema, el análisis y el protocolo por ti a partir de las anotaciones de tipo. El SDK de bajo nivel (mcp.server.Server) solo compensa cuando necesitas controlar detalles del protocolo que FastMCP oculta. Conviene saber que la línea 2.0 del SDK, en fase beta durante 2026, renombra la clase FastMCP a MCPServer; mientras tanto, la 1.x es la versión estable recomendada para producción.
¿Es seguro exponer herramientas a un modelo?
Solo si lo diseñas con cuidado. Una herramienta es código que se ejecuta, así que el protocolo exige que el usuario apruebe cada invocación y que el host obtenga consentimiento antes de compartir datos. Valida siempre los argumentos que llegan, limita lo que cada herramienta puede tocar y no confíes en las descripciones de un servidor de terceros. Si sirves el servidor por HTTP, añade autenticación y no lo expongas abierto a Internet.
Conclusión
Construir un servidor MCP propio con el SDK de Python es sorprendentemente directo: instalas mcp[cli], defines herramientas, recursos y prompts como funciones tipadas con FastMCP y eliges el transporte stdio o HTTP según dónde corra. A partir de ese servidor mínimo puedes crecer hacia herramientas que consultan tu base de datos, recursos que leen tus documentos internos o flujos que integran una API de tu empresa, y conectarlo a cualquier asistente que hable el protocolo. El siguiente paso natural es dar a tu servidor una herramienta real y probarla desde Claude o Cline antes de llevarla a tu equipo.