MCPs propios: cuándo construir vs adoptar

¿Cuándo conviene construir un MCP propio en lugar de usar uno de la comunidad?

Conviene construir un MCP propio cuando tu operación depende de reglas de negocio privadas, sistemas internos detrás de VPN, o requerimientos estrictos de latencia y gobernanza que las herramientas públicas no cubren. Si la integración solo consulta una API estándar de mercado sin transformar datos, adoptar la solución comunitaria siempre ahorra semanas de mantenimiento técnico recurrente.

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.

Comparativa técnica: Construcción interna vs. Adopción comunitaria

La siguiente matriz sintetiza las dimensiones críticas que un equipo de ingeniería debe evaluar antes de comprometer recursos de desarrollo:

Criterio	Adoptar de la comunidad	Construir servidor propio
Tiempo inicial a producción	Inmediato (minutos de configuración en JSON de cliente).	Días o semanas según la complejidad del schema Zod y pruebas.
Carga de mantenimiento	Delegada en el mantenedor del repositorio upstream.	Total: absorber breaking changes del SDK oficial y dependencias.
Superficie de ataque	Riesgo de inyección de código de terceros o dependencias vulnerables.	Control total de sanitización, secretos y filtrado de datos salientes.
Mecanismo de transporte típico	stdio para local, SSE para contenedores prearmados.	stdio para baja latencia o HTTP/SSE corporativo autenticado.
Adaptabilidad a sistemas legados	Nula: requiere que tu infraestructura se adapte a su schema.	Absoluta: permite normalizar SOAP, XML o bases on-premises.

Implicaciones técnicas para arquitecturas en México y América Latina

En el contexto corporativo de América Latina, la decisión de construir suele ganar fuerza debido a dos factores constantes: la dispersión geográfica de la nube y la prevalencia de software administrativo legado.

1. Conectividad a ERPs y servicios fiscales locales

Gran parte de las empresas en México operan sobre sistemas como Aspel, CONTPAQi o implementaciones locales de SAP. Ningún repositorio oficial de Model Context Protocol ofrece herramientas listas para consultar catálogos de cuentas con la estructura del SAT o validar facturas electrónicas bajo el esquema CFDI 4.0. Un MCP propio actúa como la capa de abstracción ideal: transforma peticiones en lenguaje natural en consultas estructuradas a bases de datos relacionales locales o llamadas SOAP a Proveedores Autorizados de Certificación (PAC), devolviendo al agente de IA únicamente el UUID, el estatus y los importes sin exponer cadenas de conexión sensibles.

2. Penalización de latencia por topología de red

De acuerdo con mediciones de latencia reportadas por la red de Cloudflare para el cono sur y México, una llamada HTTPS transcontinental hacia servidores en la costa este de Estados Unidos o Europa añade entre 120ms y 220ms por salto de ida y vuelta. Si un agente de IA encadena tres llamadas sucesivas de herramientas mediante un MCP remoto de terceros, consume más de 600ms solo en red, agotando el presupuesto de respuesta del usuario final. En este escenario, construir un MCP local que corra por stdio en la misma máquina o contenedor del orquestador reduce esa sobrecarga a menos de 10ms.

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.

Riesgos operativos: qué puede salir mal en producción

Implementar servidores MCP sin controles estrictos introduce modos de falla específicos que van más allá de una caída tradicional de servicio:

Envenenamiento de contexto por salidas no controladas

Cuando una herramienta devuelve respuestas sin limpiar (por ejemplo, volcados completos de stack traces o tablas HTML complejas), satura la ventana de contexto del LLM. Según las especificaciones de Anthropic para el manejo de contexto en Claude, saturar la memoria de trabajo con datos no estructurados incrementa la tasa de alucinaciones y degrada el razonamiento en pasos posteriores. El MCP debe devolver exclusivamente tipos primitivos o JSONs compactos diseñados para consumo de la máquina.

Inyección indirecta de prompts mediante herramientas

Si tu MCP extrae datos de fuentes no confiables (como correos de clientes, comentarios de soporte o tickets de mesa de ayuda) y los pasa directamente al modelo, un atacante puede insertar instrucciones hostiles en el cuerpo del mensaje. Todo MCP interno debe delimitar claramente la salida con metadatos estructurados que indiquen al agente que el bloque recibido corresponde a datos pasivos y no a instrucciones ejecutables del sistema.

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.