MCPs propios: cuándo construir vs adoptar

El criterio que filtra el 90% de las decisiones

Antes de abrir tu editor, contesta: ¿el MCP que necesitas ya existe y lo mantiene alguien que no eres tú? Si la respuesta es sí, adóptalo. El costo de mantener un MCP propio se subestima sistemáticamente: tienes que versionar schemas, manejar errores, paginar respuestas, instrumentar latencia y reescribir cuando el SDK cambia (y va a cambiar). El SDK de @modelcontextprotocol/sdk ha tenido tres rondas de breaking changes en 2025-2026; cada una te cuesta una tarde si tu MCP es propio.

Adopta cuando

• Es una integración estándar con un ecosistema maduro: filesystem, github, sqlite, postgres, slack. Hay implementaciones oficiales o cuasi-oficiales.
• El comportamiento que necesitas coincide en 80%+ con lo que el MCP existente ya expone.
• Las credenciales no son delicadas o el MCP soporta tu mecanismo de auth (OAuth, PAT, bearer).
• La latencia adicional de pasar por un servidor genérico no te duele (chat batch sí, chatbot en vivo no necesariamente).

Construye cuando

• Lógica de negocio propia. Tu MCP no es un wrapper de API; es una decisión. Ejemplo: core-mcp-awalab que decide qué endpoint del ERP llamar según el tipo de cliente, aplica reglas de descuento y devuelve algo curado, no el raw response.
• Endpoint privado o detrás de VPN. Si tu API solo responde desde 34.59.193.54 con cert mutuo, no vas a pasar credenciales a un MCP genérico de terceros.
• Credenciales delicadas. Tokens que dan acceso a producción no deben vivir en configuraciones de MCP que sincronizas en GitHub.
• Latencia crítica. Un MCP propio en stdio sobre proceso local agrega ~5-10ms. Uno HTTP remoto en otro continente, 200-400ms. Para un chatbot que ya tiene 1.5s de presupuesto total, es la diferencia entre fluido y lento.
• Schema que el MCP genérico no expone. Caso real: inegi-mcp existe para consultar el BISE del INEGI con manejo de las idiosincrasias del catálogo de indicadores. Ningún MCP genérico te va a entender los códigos de indicador como 1002000001.

Lo que NO debes exponer en tu MCP

Esta lista evita 80% de los incidentes:

• Mutaciones destructivas sin confirmación. Nada de delete_user, drop_table, force_push sin un parámetro confirm: true y un nombre de herramienta que grite peligro.
• Lectura recursiva sin paginación. list_all_files sobre un repo de 80k archivos te devuelve 12MB de JSON y mata el contexto. Pagina siempre, default 50.
• Secrets en respuestas. Si tu API devuelve la fila completa de la tabla users, filtra password_hash, api_keys, tokens antes de pasarla al modelo. Una vez en el contexto, salen en logs, en transcripts, en cualquier parte.
• Queries sin LIMIT. Para herramientas tipo query_database, fuerza un LIMIT máximo (1000 está bien) en el servidor, no en el prompt.

Heurística final

Si tu MCP propio va a tener menos de 5 herramientas, probablemente debería ser un slash command. Si va a tener más de 20, probablemente estás empaquetando dos MCPs distintos. El punto dulce está en 6-12 herramientas, una por caso de uso atómico, cada una con schema Zod estricto y mensajes de error humanos.

La pregunta que vale la pena hacerte: ¿este MCP encapsula conocimiento que ya está documentado en tu wiki, o crea un atajo a algo que nadie había hecho fácil de invocar? La primera categoría se desactualiza. La segunda se vuelve infraestructura.