--- title: "Capstone. Publica tu primer servidor MCP — StudioMeyer Academy" description: "Construye un pequeño servidor MCP que resuelva un problema real de tu vida y hazlo instalable para otros." canonical: "https://studiomeyer.academy/es/lernwege/fuer-entwickler/lektionen/08-capstone" language: es image: "https://studiomeyer.academy/og/academy-og-share.png" publisher: "StudioMeyer Academy, https://studiomeyer.academy (llms.txt: https://studiomeyer.academy/llms.txt)" --- 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 y escribir tus propios playbooks (también para la academy). La identidad de operator deja aquí de ser un estado final y se vuelve un hábito. Puedes leer todo libremente. Con una cuenta se guarda tu progreso. [Iniciar sesión](https://studiomeyer.academy/es/login?next=%2Fes%2Flernwege%2Ffuer-entwickler%2Flektionen%2F08-capstone) Para desarrolladores · Módulo 1 de 1 ## Para desarrolladores [Volver a la ruta](https://studiomeyer.academy/es/lernwege/fuer-entwickler) ## Tus notas Inicia sesión para guardar tus propias notas sobre esta lección. [Iniciar sesión](https://studiomeyer.academy/es/login?next=%2Fes%2Flernwege%2Ffuer-entwickler%2Flektionen%2F08-capstone) ## Sitemap Páginas públicas de este sitio como Markdown: [sitemap](https://studiomeyer.academy/sitemap.md). Punto de entrada curado: [llms.txt](https://studiomeyer.academy/llms.txt), texto completo: [llms-full.txt](https://studiomeyer.academy/llms-full.txt).