Capstone. Publica tu primer servidor MCP
Construye un pequeño servidor MCP que resuelva un problema real de tu vida y hazlo instalable para otros.
El Nivel 6 te enseñó cómo se construye, se despliega, se distribuye y se asegura con OAuth un MCP server. Y cómo los setups multi-agent orquestan el conjunto. Ahora construyes el tuyo, lo haces instalable para otros y escribes un mini doc.
Quien tiene el capstone hecho está oficialmente en operator level seis: construyes herramientas que otros pueden usar, no solo herramientas que tú usas.
La tarea
Elige un caso de uso pequeño e inequívoco de tu vida o trabajo. Ejemplos lo bastante pequeños:
- Un MCP server que consulta Wikipedia en tu idioma y devuelve formateado.
- Un MCP server que trae datos meteorológicos y responde a medida para una región concreta.
- Un MCP server que busca en tus notas de Obsidian, Notion o una carpeta Markdown.
- Un MCP server que conecta una API específica que necesitas en el trabajo (Bookwize, Cal.com, una herramienta sectorial).
- Un MCP server que encapsula un workflow recurrente (p. ej. "crear nuevo lead en CRM + email de confirmación").
Importante: no demasiado grande. Tres a cinco tools bastan. Si planeas quince tools, el capstone está demasiado grande y abandonarás frustrado.
Componentes obligatorios
Al menos tres tools. Cada uno con descripción clara, parámetros tipados (Zod o JSON schema) y output con sentido.
Validación y error handling. Las tools tienen que cortar limpiamente si los parámetros no encajan, en lugar de morir con stack traces crípticos.
Rate limiting. Si tu server llama una API externa, tiene que respetar cuotas. Es regla dura, no "nice to have".
Health endpoint si construyes HTTP transport, o un output --version claramente documentado en modo stdio.
README. Tres secciones: qué hace el server, install en 30 segundos, prompts de ejemplo.
Tests. Al menos tres tests Vitest por tool. Happy path, edge case, error case. Sin tests no has aprobado el capstone, por bonito que esté el código.
Distribución
Elige una de las tres opciones de distribución:
- npm publish como stdio server. La vía más simple, cualquiera puede engancharlo con
npx -y tu-server. - MCPize Cloud Run como HTTP transport con bearer auth. Si quieres experiencia SaaS.
- Container Docker propio en un server (p. ej. Hetzner). Si quieres control total y no plataformas externas.
Publícalo. De verdad. Make it real. Aunque tú seas el primer usuario.
El output
Un repo (público en GitHub o, si el caso es privado, en tu studio account).
Al menos un install de prueba exitoso desde una máquina distinta a la de desarrollo. Si solo arrancas el server local y dices "listo", no entendiste la distribución.
Una demo mini (screen recording o screenshots) donde usas la tool en Claude Code, Claude Desktop o Cursor y llega la respuesta.
Un post Reddit o LinkedIn corto (300-500 palabras) que explica: por qué construiste el server, cómo funciona desde la perspectiva del usuario, dónde estuvo la parte más dura. No tienes que publicarlo, pero debes escribirlo, porque escribir te obliga a explicar lo que construiste desde la perspectiva del usuario.
Criterios de auto-evaluación
- ¿La instalación funciona en una máquina nueva sin que tú ayudes?
- ¿Las descripciones de las tools son lo bastante claras para que Claude u otro agent elija la correcta sin que tú apuntales el prompt?
- ¿Tus tests son tests reales o solo escribiste expect(true).toBe(true)?
- ¿Pasaste de verdad por la distribución, o el código está "casi listo para publicar"? Lo segundo no cuenta.
Qué tienes después
Tienes un MCP server público a tu nombre, un repo que puedes enlazar en candidaturas, un post que puedes compartir en comunidades, y un trozo de software que usas tú. Cuatro pruebas a la vez de que has llegado a operator level seis.
Si quieres registrar el server en la arena (recuerdas la arena del Nivel 5 y 6), puedes ahora construir bots que usen exactamente tu server y modelar tus propios workflows. Es la siguiente etapa, no parte obligatoria del capstone.
Qué viene después
No hay Nivel 7. Cuando termines el Nivel 6 estás en un punto donde decides tú qué viene: tu propio SaaS alrededor de tu MCP server, una especialización en una industria, tu propia plataforma multi-agent para un mercado concreto, o simplemente ser mejor en lo que ya haces. La academy acaba aquí porque a partir de aquí el terreno es demasiado grande para un curso.
Qué puedes hacer: seguir luchando en la arena con bots propios, escribir tus propios playbooks (también para la academy), y contar en la comunidad Discord lo que construyas. La identidad de operator deja aquí de ser un estado final y se vuelve un hábito.