← Level 6
Level 6· Lektion 1 von 8

Planificar un servidor MCP, qué va dentro

Las preguntas más importantes antes de escribir código. La mayoría de los servidores fracasa aquí, no en el código.

El orden equivocado

Muchos devs empiezan así: "Tengo una idea para un MCP server. Que ejecute npx create-mcp y a por ello."

Tres semanas después: técnicamente funciona, pero nadie lo instala. Porque la pregunta fundamental no se respondió nunca.

Las cinco preguntas antes del código

1. ¿Qué problema resuelve el server?

No "qué hace", sino "qué problema reduce". Ejemplo: "Claude no tiene acceso a mi Lexoffice" no es un problema. "Cada mañana tengo que buscar facturas a mano para pasarlas al CRM" es un problema.

Si no puedes responderlo en una frase, todavía no construyas el server.

2. ¿Quién lo usa?

¿Solo tú? Constrúyelo local, no inviertas tiempo en docs, distribución, pricing.

¿Un equipo? Necesitas instrucciones de instalación, config, quizás multi-tenant.

¿Público abierto? Es un producto. Con pricing, marketing, soporte. Mucho más trabajo de lo que crees.

3. ¿Qué tools entran?

Trampa común: "Mi server hace TODO con X." Una lista demasiado amplia confunde al modelo. Llama la tool equivocada, mete los parámetros mal.

Regla práctica: 5-15 tools. Si tienes 40, divide el server en dos.

Y: cada tool necesita un propósito claro y único. Nada de get_data, fetch_data y read_data que hacen lo mismo.

4. ¿Stdio o HTTP?

Los stdio MCP servers corren localmente en la máquina del usuario, arrancan automáticamente cuando Claude los necesita. Más fáciles de instalar (npm install -g), sin coste de hosting.

Los HTTP MCP servers corren remotamente, el usuario da una URL, hace OAuth. Necesitan hosting, pero permiten updates centralizados y gestión de usuarios.

Regla: si el server trabaja con datos privados del usuario (archivos, credenciales), stdio. Si tiene una base de datos central compartida, HTTP.

5. ¿Cómo monetizas?

Pregúntalo pronto. Tres modelos visibles hoy:

  • Free + Open Source (comunidad, GitHub stars, pull requests; puede llevar a encargos).
  • SaaS con tiers (hosting centralizado, usuarios pagan mensual; mcp-nex lo hace).
  • Desktop/Local + Pro (server es gratis instalado, features Pro se desbloquean al pagar).

Decisión ANTES del código, no después.

Qué apuntar ahora

Antes de npm init, ten esta página:

  • Problema: una frase.
  • Audiencia: quién, cuántos.
  • Lista de tools: nombres + propósito en una frase.
  • Transport: stdio o HTTP.
  • Monetización: si la hay.

Si los cinco están claros, construyes el esqueleto en dos horas. Si no, será un mes.

La regla trabajo-vs-valor

El código de un MCP server es sencillo. 200 líneas para un buen server de 5 tools. El trabajo es:

  • 30% código
  • 30% integración de datos (APIs, rate limits, errores)
  • 20% documentación
  • 20% distribución (npm, GitHub, quizás marketplaces)

Si crees que terminas en dos semanas, planifica cuatro.

Siguiente lección

Cómo se ve el esqueleto. TypeScript, @modelcontextprotocol/sdk, el server mínimo en 40 líneas de código.

Estás leyendo sin cuenta. Login guarda tu progreso para que retomes donde lo dejaste. Iniciar sesión →