Tu Primer Servidor MCP en Python: Las 3 Primitivas Que Todos los Tutoriales Ignoran
Llevaba semanas conectando APIs manualmente a mis agentes de IA. Cada integración era un proyecto dentro del proyecto: autenticación, manejo de errores, formats distintos, prompts hardcodeados que se rompían con cualquier cambio.
Entonces me puse a leer la spec de MCP de verdad — no los resúmenes de Twitter — y me di cuenta de que estaba construyendo exactamente lo que MCP ya resuelve.
Y aquí viene lo que nadie te explica bien: MCP tiene tres primitivas, no una. La mayoría de los tutoriales solo tocan tools. Pero si no entiendes resources y prompts, estás usando el 30% del protocolo.
Vamos a arreglarlo hoy.
Primero, contexto rápido (sin fluff)
MCP — Model Context Protocol — es el estándar que resuelve el problema N×M de las integraciones de IA. En lugar de que cada modelo aprenda a hablar con cada servicio de forma diferente, MCP define un protocolo universal. Lo lanzó Anthropic en noviembre de 2024 y en 2026 ya lo han adoptado OpenAI, Google y la Linux Foundation.
La arquitectura es simple:
- Host: la aplicación de IA (Claude Desktop, tu agente custom)
- Client: el conector que vive dentro del host
- Server: tu código que expone datos y funcionalidades
Comunicación: Stdio para servidores locales (más rápido, acceso al sistema), HTTP con SSE para remotos (OAuth, cloud hosting).
Para este tutorial vamos con Stdio — lo más directo para empezar.
Las 3 Primitivas: Tools, Resources y Prompts
Piénsalas así:
Primitiva
Qué hace
Quién la invoca
Tool
Ejecuta una acción
El modelo de IA
Resource
Expone datos de solo lectura
El host / el usuario
Prompt
Plantillas de instrucción reutilizables
El usuario
Vamos con código.
Setup inicial
Creamos el archivo base servidor.py:
Primitiva 1: Tool (acción)
Un tool es lo que el modelo puede ejecutar. Buscar, crear, actualizar, eliminar. Tiene parámetros tipados y el modelo decide cuándo llamarlo.
El modelo llama a buscar_producto cuando el usuario pregunta “¿tenéis zapatillas de running?”. No le tienes que decir cuándo llamarla — eso lo decide él solo.
Primitiva 2: Resource (datos de solo lectura)
Un resource expone datos que el host puede leer y pasar como contexto. La diferencia clave con un tool: los resources no ejecutan acciones, solo devuelven información.
Útil para: configuración del sistema, catálogos completos, documentos de referencia.
Primitiva 3: Prompt (plantillas reutilizables)
Aquí es donde la mayoría falla. Un prompt en MCP no es el system prompt de tu modelo — es una plantilla de instrucción que el usuario puede invocar directamente desde el host.
Piénsalo como comandos slash (/analizar-pedido) que rellenan contexto automáticamente.
Arrancando el servidor
Para conectarlo a Claude Desktop, añades en tu claude_desktop_config.json:
Una nota sobre seguridad que no puedes saltarte
El ecosistema MCP ya tiene más de 270 servidores en producción. Con ese crecimiento vienen riesgos reales: prompt injection y tool attacks.
Reglas mínimas antes de poner cualquier servidor MCP en producción:
- Permisos mínimos: tu servidor solo debe tener acceso a lo que necesita. Nada más.
- Valida los inputs: nunca confíes en los argumentos que llegan al tool sin sanear.
- Sandboxing: si ejecutas código externo, aíslalo. Siempre.
- Nunca expongas secretos en resources: los resources son legibles por el host. Trátalos como contenido público dentro de tu sistema.
Lo que acabas de aprender
Tienes un servidor MCP funcional con las tres primitivas:
→ Tool para que el modelo ejecute acciones
→ Resource para exponer datos de contexto
→ Prompt para plantillas de instrucción reutilizables
La mayoría de los tutoriales que verás en 2026 solo te enseñan los tools. Ahora ya sabes por qué eso es quedarse a medias.
El siguiente paso real: conecta este servidor a un caso de uso tuyo — una base de datos de Supabase, tu CRM, tu sistema de tickets — y empieza a iterar. MCP no es teoría. Es infraestructura que ya está en producción en empresas como Block y Apollo.
Seguimos construyendo.
