Build vs buy de servidor MCP: cuándo construirlo y cuándo comprarlo

Un servidor MCP es un proceso backend que expone herramientas, recursos y prompts sobre el transporte Streamable HTTP, de modo que un cliente de IA como Claude, Cursor o ChatGPT pueda llamarlos como capacidades de primer nivel. La pregunta build vs buy es si levantar ese backend tú mismo o dejar que un proveedor gestionado lo opere por ti. La respuesta honesta en 2026: comprar para el 80% de las integraciones que son commodity, construir para el 20% en que el servidor MCP es parte de tu producto o toca datos que no puedes entregar a un tercero.

La decisión pesa porque la brecha de costes es amplia. Los servidores MCP a medida cuestan 50.000-150.000 dólares por integración al año una vez cuentas auth, gobernanza y mantenimiento. Un servidor gestionado para la misma integración suele costar una fracción, con el trade-off de entregar la superficie de herramientas a un proveedor. La pregunta no es "cuál es mejor" en abstracto. Es "para esta integración, en esta etapa, qué conjunto de trade-offs encaja".

TL;DR: quién elige qué

• Compra si te conectas a un SaaS popular (Slack, Notion, GitHub, Google Drive, Stripe), necesitas OAuth y audit logs desde el día uno y quieres a tus ingenieros en el producto en vez de en el plumbing.
• Construye si el servidor MCP es el producto (vendes acceso de IA a un sistema específico), los datos son regulados o propietarios, o ningún proveedor gestionado cubre la superficie que necesitas.
• Híbrido es el estado final estable para la mayoría de los equipos: compra las superficies commodity, construye las dos o tres que te diferencian o que son sensibles.

Qué estás comprando en realidad

Cuando decimos comprar, queremos decir apuntar un cliente de IA a un servidor MCP gestionado por un tercero. Las opciones principales a inicios de 2026:

• Cloudflare Agents. Servidores MCP remotos gestionados con OAuth vía workers-oauth-provider, MCP Server Portals para enrutado centralizado y un catálogo de servidores first-party para las APIs de Cloudflare.
• Truto, Composio, Kong MCP Gateway. Gateways multi-tenant que envuelven cientos de APIs SaaS detrás de una integración registrada, con OAuth, rate limiting y permisos a nivel de herramienta.
• Official MCP Registry en registry.modelcontextprotocol.io, que no aloja servidores sino que publica un catálogo verificado que apunta a paquetes npm, PyPI o Docker.
• Servidores gestionados first-party de GitHub, Atlassian, Notion y otros, operados por el propio proveedor SaaS para su superficie de producto.

Gartner proyecta que para 2026 el 75% de los proveedores de API gateway y el 50% de los proveedores iPaaS enviarán funcionalidad MCP. Comprar ya no es una apuesta de early adopter.

Los ejes que realmente deciden

Tiempo hasta la primera herramienta funcional

Comprar te lleva de cero a una herramienta MCP funcional en horas. Construir lo mismo toma 80-120 horas para un conector de base de datos simple y 150-250 horas para un servidor de integración de API, con 400-800 horas para orquestación multi-sistema. Si necesitas la herramienta en producción este trimestre, esa brecha es el argumento entero.

Autenticación

El primer muro que golpea cada equipo self-hosted es OAuth. La revisión 2025-06-18 de la especificación hizo OAuth 2.1 obligatorio para servidores remotos. Los servidores gestionados lo entregan por defecto. Hacerlo en casa significa implementar dynamic client registration, pantallas de consentimiento, token exchange, manejo de refresh y enforcement de scopes. Bibliotecas como el OAuth provider de Cloudflare cortan bastante trabajo, pero sigue siendo tuya la integración con los proveedores de identidad (GitHub, Google, WorkOS, tu propio IdP).

Postura de seguridad

Los servidores MCP tienen una superficie de ataque nada trivial. En 2025 e inicios de 2026 se divulgaron CVE-2025-53818 (command injection en el GitHub Kanban MCP server), CVE-2025-53110 (sandbox escape en el servidor filesystem MCP de referencia) y un fallo en el SDK MCP de Anthropic que afectó a más de 7.000 servidores accesibles públicamente. La prompt injection indirecta vía output de herramientas sigue siendo una clase de riesgo sin resolver, documentada por Microsoft, por Palo Alto Unit 42, y por Simon Willison. Un proveedor gestionado se lleva el parcheo, la divulgación y el rastro forense. Un servidor self-hosted deja ese trabajo a tu equipo, de forma indefinida.

Coste a escala

A un coste de ingeniería cargado de 100 dólares la hora, un servidor MCP a medida de tamaño medio consume 1.200-2.600 dólares al mes solo en tiempo de mantenimiento. Multiplica por diez integraciones y tienes dos FTE presupuestados puramente en plumbing MCP. El precio gestionado suele entrar como per-seat o per-call con un suelo por debajo de los 1.000 dólares al mes por integración. El break-even llega antes de lo que la mayoría de los equipos espera, normalmente dentro de los primeros seis meses a partir de la tercera integración.

Residencia de datos y cumplimiento

Un servidor MCP gestionado ve, como mínimo, los argumentos de las herramientas y los valores de retorno que pasan por él. Para datos regulados por HIPAA, GDPR, PCI o datos propietarios del cliente, eso suele ser no negociable sin un DPA firmado, una garantía de despliegue regional y un derecho de auditoría. No todos los proveedores gestionados ofrecen los tres. Construir mantiene los datos dentro de tu VPC y el control plane dentro de tu SOC.

Velocidad del protocolo

La especificación MCP ha enviado tres revisiones mayores desde finales de 2024: el release inicial de noviembre de 2024, la revisión 2025-03-26 que introdujo Streamable HTTP y auth remota, y la revisión 2025-06-18 que hizo OAuth 2.1 obligatorio y añadió elicitation. La hoja de ruta 2026 añade operaciones asíncronas, contenido multi-modal y patrones agente-a-agente más fuertes. Los servidores gestionados absorben el churn del protocolo. Los self-hosted te obligan a releer la especificación cada trimestre y enviar una migración de cliente con cada cambio que rompe compatibilidad.

Dónde gana construir

Cuando el acceso MCP es el producto

Si vendes acceso de IA a un sistema específico que nadie más posee (un SaaS vertical, un dataset propietario, un flujo de industria regulada), el servidor MCP no es plumbing, es la superficie que tus clientes pagan. Construirlo es una inversión de producto, no un coste. La economía se da la vuelta: las 400-800 horas que gastarías son también las horas que ya estás gastando en diseñar la API, y la carga de mantenimiento es la misma que ya llevas en tu API pública.

Cuando los datos no pueden salir de tu perímetro

Registros financieros de clientes, registros médicos, discovery legal o investigación propietaria no pueden pasar por un gateway de terceros sin cambios de contrato que la mayoría de los compradores enterprise no firmarán. En ese caso la única pregunta es sobre qué stack construyes. Cloudflare Workers con el Agents SDK es la rampa de acceso más rápida. Un proceso Node o Python detrás de tu ingress existente también funciona, siempre que termine OAuth correctamente.

Cuando ningún proveedor gestionado cubre la superficie que necesitas

El ecosistema MCP es amplio pero desigual. Las superficies comunes (Slack, Notion, GitHub, Google Workspace, bases de datos principales) tienen tres o cuatro opciones gestionadas cada una. Las superficies de nicho (el ERP interno de tu empresa, una API vertical de industria, un servicio de inferencia a medida) tienen cero. Si el único proveedor que ofrece tu sistema es el propio proveedor SaaS, y su servidor no expresa las herramientas que realmente necesitas, construir es el plan B.

Cuando necesitas control a nivel de herramienta más allá de lo que expone el proveedor

Los servidores MCP gestionados exponen normalmente un set curado de herramientas. Si necesitas herramientas que el proveedor no ha construido, componer herramientas a través de sistemas que el proveedor maneja por separado, o lógica de autorización atada a tus propios roles y permisos, las escribes tú.

Dónde gana comprar

Cuando la integración es commodity

Las integraciones con las plataformas SaaS principales son casi idénticas entre empresas. El flujo OAuth es el mismo. La lista de herramientas es la misma. Los rate limits son los mismos. Pagar a un proveedor para que lo mantenga una vez, para todos, y repercutir el coste a los clientes (o amortizarlo en tu propio producto) cuesta menos que reinventarlo equipo por equipo.

Cuando lo necesitas en producción esta semana

La velocidad importa cuando las funcionalidades de IA son una apuesta competitiva y no una inversión de plataforma. Un equipo que envía un asistente de IA en dos semanas usando MCP gestionado captura el mercado que el equipo que aún está escribiendo OAuth en su servidor a medida pierde.

Cuando tu equipo de seguridad ya está estirado

MCP añadió aproximadamente 200.000 servidores nuevos accesibles públicamente a la superficie de ataque en 2025. Las divulgaciones de vulnerabilidades han sido frecuentes. Si tu equipo de seguridad ya no se da abasto con Dependabot, un servidor MCP self-hosted es un pasivo que el proveedor gestionado cobra por llevar.

Cuando quieres un único panel de gobernanza

Cloudflare MCP Server Portals o Kong MCP Gateway te dan un endpoint único para monitorizar, rate-limitar y auditar, aunque los servidores detrás sean varios. Construir esa capa de gobernanza por tu cuenta es un segundo proyecto encima de los servidores mismos.

Qué hacemos en Studio

Vamos por defecto al patrón híbrido. Para integraciones SaaS que un cliente ya usa (Slack, Notion, GitHub, Stripe), conectamos un servidor MCP gestionado y dedicamos nuestro tiempo a la lógica de agente que lo llama. Para el acceso a la base de datos propia del cliente, a sus servicios internos o a los datos de sus clientes, construimos un servidor MCP pequeño sobre Cloudflare Workers con el Agents SDK, típicamente 2-3 semanas incluyendo OAuth, audit logs y despliegue. Para ver en profundidad cómo es ese build dentro de un codebase existente, mira nuestra guía sobre cómo construir un servidor MCP para un SaaS Next.js existente, y el encuadre de producto en qué es MCP y cuándo un SaaS lo necesita.

Dos reglas que mantenemos. Primero, ningún servidor MCP en producción corre sin OAuth 2.1 y audit logs, ya sea gestionado o construido. Segundo, el servidor MCP nunca es el lugar donde las funcionalidades nuevas prototipan primero. Prototipamos en un servidor stdio local, luego promovemos a un servidor remoto con auth reforzada cuando la funcionalidad se lanza.

Cómo decidir para tu caso

Recorre los ejes en orden y detente en el primero que fuerce la respuesta.

1. ¿Los datos pueden salir de tu perímetro legalmente? Si no, construye.
2. ¿El servidor MCP es un producto que vendes? Si sí, construye.
3. ¿Un proveedor gestionado cubre este sistema con las herramientas que realmente necesitas? Si no, construye.
4. ¿Tu equipo necesita una integración funcional en dos semanas? Si sí, compra.
5. ¿Tu equipo de seguridad puede hacerse cargo de un servicio público nuevo de forma indefinida? Si no, compra.
6. ¿Es esta una de las tres integraciones que hacen que tus agentes sean distintos de los de todos los demás? Si sí, plantéate construir. Si no, compra.

El error que vemos más a menudo son equipos que eligen construir por defecto porque MCP parece simple en una demo de cinco minutos, y seis meses después descubren que han gastado más en plumbing MCP que en las funcionalidades de IA que iba a habilitar. Construye donde construir se lo gana, compra en todo lo demás.