Implementar un Servidor MCP en Python y TypeScript
El Covert: la base de operaciones que expone capacidades
En Nevarro existe un Covert — la base secreta de los Mandalorianos. Está oculta bajo la ciudad, acceso controlado, y solo entra quien conoce el Credo. Dentro del Covert hay tres tipos de servicios: acciones que modifican el mundo (forjar armadura, reparar naves), datos que podés consultar (el registro del Gremio), y templates estandarizados (el Juramento Mandaloriano — siempre la misma formulación).
Eso es exactamente un servidor MCP: una entidad que expone capacidades a clientes que se conectan siguiendo el protocolo correcto. Las tres primitivas del Covert son las tres primitivas de MCP: tools con efectos secundarios, resources de solo lectura, y prompts como templates reutilizables.
En este video construís el servidor desde cero — dos veces. Primero en Python, después en TypeScript. Y al final lo conectás a Claude Code para verificar que funciona en producción real.
Este es el video más técnico del Módulo 2. No hay trucos de memoria ni analogías creativas para salvar. Hay que entender la estructura, el código, y las diferencias entre lenguajes. Pero si llegaste hasta acá en el curso, ya tenés todo lo necesario.
Las tres primitivas: lo que el Covert expone
Antes de escribir una línea de código, hay que tener claro qué puede exponer un servidor MCP. Son exactamente tres tipos de capacidades, y cada una tiene un contrato diferente con el cliente:
[tabla]
La distinción más importante para el examen: tools tienen side effects (modifican estado), resources son read-only (nunca modifican nada). El examen pregunta esto directamente.
En el Covert Mandaloriano: la tool aceptar_contrato modifica el estado del sistema — registra un contrato nuevo, y eso cambia la base de datos. El resource del registro del Gremio solo devuelve información — nunca puede usarse para modificar quién está buscado o cuánto vale su cabeza. El prompt del Juramento es un template — define cómo empezar una operación de caza, pero es texto, no acción.
Primera decisión de arquitectura: ¿cómo se conecta el cliente?
Antes de construir el servidor, hay una decisión que cambia el deployment completo: el transporte. MCP soporta dos formas de conectar cliente y servidor, y la elección depende del contexto de uso:
[tabla ]
💡 Para Claude Code y desarrollo local: siempre stdio. Para producción con múltiples agentes o acceso remoto: HTTP con SSE.
En los demos de este video usamos stdio. El servidor corre como proceso en tu máquina, Claude Code se comunica con él por standard input/output, y cuando Claude Code termina, el proceso del servidor también termina. Sin configuración de red, sin puertos, sin autenticación explícita.
🎯 TRAMPA DE EXAMEN: El examen puede preguntar cuándo usar cada transporte. Regla simple: stdio = local + Claude Code. HTTP/SSE = producción + múltiples clientes + acceso remoto.
Demo A: el servidor completo en Python
Instalación primero:
El servidor Python usa decoradores para registrar handlers de cada primitiva. La estructura base:
covert_server.py — Estructura base e identidad del servidor
El nombre que le das al servidor es lo que el cliente ve cuando lista los servidores disponibles. Elegilo descriptivo — es la identidad del Covert en el ecosistema.
Tool: aceptar_contrato — lógica de negocio dentro del servidor
La validación de negocio va adentro del servidor, no en el agente. El servidor es el dueño de las reglas: 'no podés aceptar dos contratos para el mismo objetivo'. El agente recibe el error y lo procesa, pero nunca tiene que conocer esas reglas internamente.
Resource y Prompt — las otras dos primitivas
⚠️ El flush=True es crítico en stdio. Sin él, el buffer de salida puede quedar pendiente y el cliente no recibe los mensajes. En Python, print tiene buffer por defecto — siempre especificá flush=True en servidores stdio.
covert_server.ts — Estructura base y tool
Resource, Prompt y punto de entrada en TypeScript
CRÍTICO para el examen: en servidores MCP con stdio en TypeScript, NUNCA usés console.log() para logs internos. Stdout está reservado para la comunicación MCP — si lo contaminás con logs, el cliente no puede parsear las respuestas y el servidor falla. Siempre usá console.error() que va a stderr.
Python vs TypeScript: las diferencias clave
La estructura lógica es idéntica en ambos lenguajes. Lo que cambia es cómo se registran los handlers:
[tabla]
💡 Para el examen: en Python se usan decoradores (@app.list_tools), en TypeScript se usan setRequestHandler con schemas. La lógica de negocio adentro es la misma.
Autenticación: el Credo como protocolo de acceso
El Covert de Nevarro tiene una regla: nadie entra sin ser parte del Credo. No hay visitantes informales. En un servidor MCP con transporte HTTP, la autenticación es explícita y obligatoria. El cliente tiene que presentar credenciales en cada request.
[tabla]
Middleware de autenticación para servidor MCP con HTTP (fragmento)
Para stdio local (Claude Code en tu máquina), la autenticación es implícita: el proceso solo es accesible desde el host local. Suficiente para desarrollo. Para HTTP en producción, siempre implementá el middleware de autenticación en la capa de transporte.
Conectar el servidor a Claude Code
El paso final: decirle a Claude Code que el Covert existe. Para eso editás el archivo de configuración settings.json — o lo agregás en el CLAUDE.md del proyecto:
.claude/settings.json — Registrar el servidor MCP
Claude Code arranca el proceso automáticamente cuando iniciás una sesión. Para verificar que el servidor está conectado:
Eso es el pipeline completo: servidor MCP corriendo localmente → Claude Code como cliente → agente que usa las herramientas en lenguaje natural → servidor procesa la lógica de negocio → devuelve resultado. This is the Way.
Trampas de examen: lo que te preguntan en el CCA-F
🎯 TRAMPA DE EXAMEN: '¿Cuándo se usa stdio vs HTTP?' No es una preferencia personal — es una decisión de arquitectura: stdio para local + Claude Code, HTTP/SSE para producción + múltiples clientes + acceso remoto.
This is the Way
En este video construiste un servidor MCP completo — dos veces. Las tres cosas que tienen que quedarte claras para el examen: el servidor es el dueño de la lógica de negocio, no el agente. El transporte stdio es para local, HTTP para producción. Y en TypeScript con stdio, los logs van siempre a stderr — nunca a stdout.
Resumen de conceptos: 3 primitivas (tools con side effects, resources read-only, prompts como templates). 2 transportes (stdio para local, HTTP/SSE para producción). 1 regla clave: lógica de negocio en el servidor, no en el agente.
En M2V4 vemos cómo distribuir herramientas en sistemas multi-agente: qué tools le das a cada agente según el principio de menor privilegio, y cómo organizás los MCP servers entre coordinador y subagentes para que el sistema escale sin perder seguridad ni claridad de razonamiento.