Toda herramienta corporativa relevante —CRM, base de datos, sistema de tickets, hoja de cálculo, repositorio de código— está decidiendo, en este momento, si expone un servidor Model Context Protocol (MCP). Ya no es pregunta de early adopter. En abril de 2026 el ecosistema ya superaba los 9.400 servidores MCP públicos, con una estimación de otras 3 a 4 veces esa cifra en servidores privados internos de empresas —más de 10.000 servidores enterprise y más de 97 millones de descargas del SDK. Anthropic, OpenAI, Google, Microsoft y AWS ya adoptaron el protocolo. Esto dejó de ser un experimento y se volvió infraestructura.
MCP resuelve un problema estructural que quedaba invisible mientras solo existían pocos agentes en producción: cada combinación de agente y herramienta exigía una integración propia. Un agente de atención que necesita consultar el CRM, abrir un ticket y revisar inventario tenía tres integraciones a medida. Cambiar de proveedor de LLM significaba reescribir las tres. El crecimiento era combinatorio: N agentes por M herramientas, sin reutilización —el mismo problema que hace que orquestar múltiples agentes salga más caro que consolidar en uno solo cuando nadie piensa en reutilizar la conexión.
El problema que existía antes del MCP
Antes del protocolo, "conectar un agente a una herramienta" significaba escribir una función, describirla en lenguaje natural para el modelo, manejar autenticación, versionar el contrato a mano, y repetir ese proceso para cada par agente-herramienta. Los frameworks de agentes intentaron abstraer la repetición con capas propias —lo que resolvía la duplicación de código, pero no la duplicación de integración: el backend del CRM seguía necesitando exponer una API específica para cada framework que quisiera consumirlo.
MCP separa dos roles que estaban fundidos. Por un lado, el servidor MCP —mantenido por quien conoce el sistema— expone tres primitivas estandarizadas: tools (funciones que el agente puede invocar), resources (datos que el agente puede leer) y prompts (plantillas reutilizables). Por otro, el cliente MCP —dentro del agente, de cualquier framework— descubre y consume esas primitivas mediante un protocolo común, sin necesitar saber nada sobre la implementación interna del sistema.
Antes del MCP, cada agente volvía a aprender a hablar con cada herramienta. Ahora la herramienta aprende a hablar MCP una vez, y cualquier agente compatible ya la entiende.
Qué cambia para quien decide la arquitectura
La consecuencia práctica es que el costo marginal de conectar un nuevo agente a un sistema existente baja —pero el costo de mantener ese sistema expuesto sube. Exponer un servidor MCP significa aceptar tráfico de clientes que no controlás individualmente, con un contrato de herramienta que necesita versionado serio y una superficie de auditoría nueva.
Eso ya cambió el comportamiento de los proveedores. Treinta por ciento de los proveedores de aplicaciones enterprise van a lanzar su propio servidor MCP —lo que incluye capas de CRM y datos que hoy solo se conectaban vía API REST propietaria o webhook. Cuando Data Cloud deja de ser solo un CDP y pasa a ser el nervio central de Salesforce, exponer esa capa vía MCP significa que cualquier agente externo compatible —no solo el nativo de la plataforma— puede consultar el mismo grafo de datos del cliente, con gobernanza del lado del servidor, no del lado de cada integración a medida.
Para quien decide arquitectura hoy, la pregunta ya no es "¿adoptamos MCP?" —es "¿cuáles de nuestros sistemas internos vale la pena exponer como servidor, y con qué control de acceso?". Un sistema con dato sensible y alto valor de reutilización justifica invertir en exponerlo bien. Un sistema de uso único, sin candidato a segundo consumidor, no justifica el mantenimiento extra.
¿MCP reemplaza el function calling nativo?
No lo reemplaza —resuelve un problema distinto. El function calling nativo (el tool use de OpenAI, el de Anthropic) ya permite que un modelo invoque una función descrita en JSON Schema dentro de una única aplicación. Esa sigue siendo la capa correcta cuando controlás los dos lados: el agente y la herramienta viven en el mismo código, sin necesidad de descubrimiento dinámico ni de reutilización por terceros.
MCP entra en juego cuando el servidor y el cliente son mantenidos por equipos o empresas distintas, o cuando el mismo servidor necesita atender a múltiples agentes con necesidades distintas a lo largo del tiempo —sin que quien mantiene el servidor necesite saber, de antemano, quién va a consumirlo. Es la diferencia entre escribir una función privada y publicar una API versionada: las dos resuelven "mi código llama a otro código", pero en alcances de responsabilidad distintos.
Cuándo vale la pena adoptarlo ahora
No es una decisión binaria de "todos lo necesitan". Tres criterios ayudan a decidir si este es el momento de invertir en exponer —o consumir— MCP:
- Reutilización real, no hipotética. ¿Hay hoy, o en un roadmap concreto de dos trimestres, más de un agente o framework que va a necesitar acceder al mismo sistema? Es la misma lógica de validar si un agente es la respuesta correcta antes de multiplicar integraciones —antes de exponer un servidor, vale confirmar que el proceso detrás ya está maduro. Si la respuesta es "solo un agente, solo un caso de uso", la integración directa sigue siendo más simple y más barata de mantener.
- Gobernanza del lado correcto. Exponer vía MCP mueve el control de acceso hacia adentro del servidor —quién puede llamar qué tool, con qué alcance. Si ese control no existe ni en la API actual, agregar MCP encima no resuelve el problema de gobernanza; solo cambia dónde aparece.
- Capacidad de versionar sin romper al cliente. Un servidor MCP en producción necesita un contrato estable. Si el equipo responsable todavía cambia el schema de la API sin avisar, publicar eso como servidor MCP multiplica el radio de ruptura —de un cliente interno a cualquier agente externo que haya descubierto la tool.
Si cumple los tres, la inversión vale la pena. Si falla en dos o más, conviene primero ordenar la casa antes de publicar eso como superficie para terceros.
El patrón que se forma ahora es el que va a durar
La velocidad de adopción —de cero a 10.000 servidores enterprise en poco más de un año— sugiere que MCP se volvió el vocabulario común entre agente y herramienta, del mismo modo que REST se volvió el vocabulario común entre frontend y backend. Quien decide exponer un sistema como servidor MCP hoy está, en la práctica, decidiendo el contrato que va a regir la integración de agentes durante los próximos años. Merece el mismo cuidado que cualquier API pública —porque, efectivamente, eso es lo que se está publicando.