Una empresa elige Copilot, lo conecta a SharePoint y a un par de APIs internas, forma a toda la plantilla y firma el contrato. Dieciocho meses después cambian los precios, o el modelo de un competidor pasa a ser mejor justo en la tarea que importa, y cambiar significa rehacer todas las integraciones desde cero. El modelo nunca fue lo caro. Lo caro era el cableado.
Ese cableado es el activo. El proveedor que se apoya encima (Claude, ChatGPT, Copilot o algo que ejecutes en tu propio hardware) es un cliente que puedes sustituir. En cuanto separas esas dos cosas, la dependencia del proveedor deja de ser un problema estratégico y pasa a ser un detalle de configuración.
Lo que permite separarlos es el Model Context Protocol. Anthropic publicó MCP en noviembre de 2024 como una forma abierta de que un modelo de IA llame a herramientas y lea datos a través de una interfaz estándar. Lo que le importa a una empresa no es la especificación en sí, sino lo que esa especificación hizo posible: describes tus sistemas como herramientas MCP una sola vez y cualquier asistente compatible puede usarlas.
Lee el diagrama de arriba abajo. El proveedor de arriba está alquilado. La definición del agente, en el medio (sus instrucciones, la lista de herramientas que puede llamar y los permisos asociados a cada una), es un contrato que escribes tú. Los servidores MCP de abajo, detrás de tu propio proveedor de identidad, son la parte que construyes y conservas. Cambia el de arriba y las dos capas de abajo ni se enteran.
Así se reparte el trabajo. Cada servidor MCP expone un conjunto de herramientas, que no son más que tus sistemas y aplicaciones descritos de una forma que un modelo puede invocar: busca este cliente, lee este documento, crea este ticket, consulta los días de vacaciones de esta persona. Eso es un servidor MCP, una lista tipada de acciones sobre software que ya tienes en marcha.
El modelo es quien conduce. Alguien escribe una petición en lenguaje natural, el modelo decide qué herramientas llamar y en qué orden, y luego convierte los resultados estructurados en una respuesta que una persona puede leer. Nadie aprende una API. Preguntas y el modelo traduce en las dos direcciones. Esta es la parte de verdad difícil, y es también la que puedes cambiar, y ahí está el truco: el trabajo de hacer que tus sistemas se manejen en lenguaje natural vive en una capa que no es tuya y que puedes reemplazar.
Como las herramientas son piezas sueltas, las combinas. Lee un PDF, extrae los campos, localiza al cliente en el CRM, redacta una respuesta, abre un ticket: cinco herramientas, una petición, un flujo de trabajo de verdad. Cada herramienta es una pieza que cualquier agente puede coger, así que lo que montas para una tarea se convierte en piezas que reutilizas en la siguiente. Un puñado de herramientas bien elegidas da para docenas de flujos de trabajo sin tener que integrar nada nuevo.
Esto ya no es cosa de un solo proveedor
Si MCP siguiera siendo solo el protocolo de Anthropic, apostar por él sería otra forma de dependencia. No lo es. OpenAI adoptó MCP en marzo de 2025 en su Agents SDK, la Responses API y la app de escritorio de ChatGPT. Google confirmó su soporte en Gemini por las mismas fechas. Microsoft enseñó soporte para MCP en Windows 11 en el Build 2025, y en diciembre de 2025 los agentes declarativos de Microsoft 365 Copilot también pasaron a admitir MCP, lo que significa que un agente creado para Copilot puede llegar a las mismas herramientas y datos que usa un agente de Claude o ChatGPT.
Después Anthropic regaló el protocolo. El 9 de diciembre de 2025 donó MCP a la Agentic AI Foundation, un fondo dentro de la Linux Foundation cofundado por Anthropic, Block y OpenAI, con Google, Microsoft, AWS, Cloudflare y Bloomberg detrás. Competidores que no se ponen de acuerdo en casi nada ahora comparten la gobernanza de esto. El mismo anuncio pone las cifras de adopción en contexto: más de 10.000 servidores MCP públicos activos, más de 97 millones de descargas mensuales de los SDK entre Python y TypeScript, y más de 75 conectores solo en Claude.
Un estándar gobernado por una fundación neutral e implementado por todos los grandes proveedores es justo el tipo de cosa sobre la que merece la pena construir. La gracia de un servidor MCP que escribes tú es que funciona en ChatGPT, Cursor, Gemini, Microsoft Copilot y VS Code sin que tengas que portar nada.
OAuth es lo que hace seguro poner esto delante de sistemas reales
Un protocolo que conecta la IA a tu CRM solo sirve si respeta quién puede ver qué. El diseño aquí es mejor de lo que tenía que ser, y la suposición de que MCP más un proveedor de identidad corporativo te da un endpoint reutilizable y seguro es correcta.
Un servidor MCP actúa como servidor de recursos OAuth 2.1. No gestiona los inicios de sesión. Valida tokens emitidos por un servidor de autorización aparte, que es el proveedor de identidad que ya usas: Microsoft Entra, Okta, Auth0 o Keycloak. El flujo sigue las convenciones estándar de OAuth que detalla la especificación: metadatos del recurso protegido para que los clientes descubran dónde autenticarse, indicadores de recurso para que un token destinado a un servidor no se pueda reutilizar contra otro y PKCE obligatorio. Cuando un usuario conecta un asistente, da su consentimiento a través de tu IdP, y el servidor MCP aplica los scopes y el control de acceso por roles internamente en cada llamada.
De ahí se siguen dos cosas. Una: el proveedor de IA nunca ve una contraseña ni guarda una credencial de larga duración; lleva un token de corta duración y con permisos acotados que emitió tu IdP y que comprueba tu servidor. Dos: como la autenticación es OAuth a secas, el mismo endpoint protegido funciona con cualquier cliente compatible. No construyes una vía de autenticación para Claude y otra para Copilot. Construyes una, y la especificación se encarga del resto.
El servidor en producción de Atlassian es un buen ejemplo. Su servidor MCP remoto para Jira y Confluence usa OAuth 2.1 para que, en sus palabras, todas las acciones respeten los controles de acceso que ya tiene el usuario. Un agente no puede leer un tablero que la persona que lo maneja no pudiera leer ya. Esa es la propiedad que quieres en cada servidor que levantes: cada acción se ejecuta como el usuario que la pidió, con los permisos de ese usuario, no con un superconjunto.
Esa garantía vale lo que valga tu configuración. El protocolo te da el mecanismo; acotarlo bien sigue siendo cosa tuya. Dale a un servidor un token demasiado amplio, o sáltate las comprobaciones de scope por herramienta, y el agente acaba con más alcance que la persona que lo maneja, lo cual es un error de montaje, no un fallo de MCP. Bien hecho, OAuth significa que nunca tienes que dar al proveedor de IA acceso permanente a nada: recibe un token de corta duración, para un usuario, con los permisos que concediste, y tu servidor comprueba las tres cosas en cada llamada.
Los puntos de integración que de verdad compensan
Es fácil asentir ante una arquitectura abstracta, así que esto es lo que la gente está conectando y por qué.
ChatGPT
Copilot
SharePoint
SalesforceLa entrada de documentos es la primera victoria evidente porque es tediosa y de mucho volumen. Subes un PDF, el agente extrae los campos, los contrasta con los sistemas de registro y presenta un borrador relleno para que una persona lo apruebe. Un ejemplo de onboarding de RR. HH., según el proveedor, describe cómo recortar un proceso de dos horas y varios sistemas a una revisión de 15 minutos, con una reducción de en torno al 70% del tiempo de tramitación por contratación. Toma esa cifra exacta como lo que es, una afirmación del proveedor y no una medición independiente, pero la idea de fondo es cierta: el trabajo consiste en leer un documento y copiar su contenido en cuatro sitios, y eso es justo lo que hace bien un agente con las herramientas adecuadas.
Las consultas de clientes en el CRM y el ERP son la segunda. Conecta el agente a los sistemas donde vive el estado del cliente y podrá sacar su historial, marcar cuentas en riesgo o resumir incidencias abiertas sin que nadie tenga que pasar por cinco pestañas. Hay servidores MCP para Salesforce, HubSpot y Zendesk, y el servidor MCP de Power Apps de Microsoft conecta a los agentes con las tablas de Dataverse en Dynamics 365, donde pueden recoger un disparador como un correo entrante y actuar sobre los datos estructurados que hay detrás.
Los datos de RR. HH. y de personas son el tercero, y donde el acceso acotado más importa. Agregadores como Unified.to exponen sistemas de RR. HH., ATS y CRM a través de una sola capa MCP que gestiona la autenticación y los permisos en cientos de plataformas SaaS, de modo que un agente puede responder «cuántos días de vacaciones le quedan a esta persona» sin que escribas una integración a medida para cada sistema.
No tienes que construir todo esto. Buena parte ya existe como servidores remotos alojados y protegidos con OAuth. Cloudflare tiene servidores MCP remotos con Atlassian, Block, Intercom, Linear, PayPal, Sentry, Stripe y Webflow, todos con permisos gestionados mediante OAuth. Para los sistemas propios de tu empresa, escribes el servidor; para las herramientas SaaS habituales, casi siempre te basta con conectarte a uno.
El ejemplo más ilustrativo es una empresa que apostó fuerte. Block construyó sus servidores MCP en casa en vez de tirar de terceros, lo que le dio control sobre la seguridad y le permitió adaptar las integraciones a sus propios flujos de trabajo. Conectó Snowflake, Jira, Slack, Google Drive y APIs internas a su agente de código abierto, Goose, y lo puso en manos de los equipos de ingeniería, datos, diseño y soporte. Ingeniería lo usa para refactorizar código heredado y ejecutar migraciones; soporte y producto lo usan para tramitar tickets y generar documentación. La misma infraestructura, mucha gente que la usa.
Los riesgos, sin adornos
Nada de esto sale gratis, y los modos de fallo son lo bastante concretos como para ponerles nombre.
El más grave es la inyección de prompts indirecta. Si tu agente lee un documento, un correo o una página web, un atacante puede esconder instrucciones en ese contenido y puede que el modelo las siga. Un ataque emparentado es el envenenamiento de herramientas, donde las instrucciones maliciosas se ocultan en la descripción o los metadatos de una herramienta, no en lo que escribe el usuario. Un análisis informa de que el envenenamiento de herramientas funciona el 84,2% de las veces en pruebas controladas cuando los agentes tienen activada la aprobación automática; es una cifra de laboratorio, no una tasa real de uso, pero la lección se sostiene: aprobar de forma automática llamadas a herramientas sobre entradas no fiables es la manera de salir escaldado. Súmale agentes con privilegios de más, credenciales desperdigadas por servidores que nadie controla y puntos ciegos de auditoría, y tienes una superficie de ataque de verdad.
Las mitigaciones no tienen nada de exótico. La guía de seguridad de la especificación de MCP es directa con lo básico: usa tokens de corta duración, valida cada token y la audiencia a la que va dirigido, acota los permisos por herramienta en vez de dar acceso a todo, y no te montes tu propia validación de tokens. Además, una pasarela o un proxy en medio te da un único sitio donde aplicar políticas, registrar cada llamada y mantener el tráfico dentro de tu red, que es justo a lo que los equipos de seguridad acaban llegando. Aquí el trabajo es de gobernanza, la misma que querrías alrededor de cualquier sistema que pueda tocar datos de clientes.
Hay un límite que conviene decir sin rodeos. MCP estandariza cómo un asistente habla con tus herramientas. Todavía no estandariza del todo la definición del agente entre proveedores; iniciativas como el proyecto AGNTCY de la Linux Foundation trabajan en descripciones de agente portables, pero esa capa es más joven que MCP y está menos asentada. Así que lo que se puede afirmar con fuerza, y demostrar, es lo de la capa de herramientas y datos: esa parte es portable hoy. Las instrucciones y la orquestación del agente quizá necesiten algún retoque al cambiar de proveedor. Es un coste mucho menor que rehacer las integraciones, que es el coste que de verdad intentas evitar.
Un plan que puedes ejecutar en tu propia empresa
Empieza por listar los tres a cinco sistemas que un agente necesitaría tocar realmente. No todos, solo los pocos que aparecen en las peticiones reales de la gente: seguramente tu CRM, tu sistema de tickets, un repositorio de documentos y una base de datos. Resiste la tentación de conectarlo todo de golpe.
Levanta un servidor MCP delante del camino de lectura de más valor antes de construir ninguno de escritura. La consulta de clientes es un buen primer objetivo porque es útil de inmediato y una lectura no puede corromper nada. Ponlo detrás del proveedor de identidad que ya usas, con OAuth, para que el agente herede los permisos de cada usuario desde el primer día y no tengas que gestionar un juego de credenciales aparte.
Luego demuestra que la portabilidad es real, porque esa es toda la premisa. Apunta dos proveedores distintos al mismo servidor, Claude y Copilot, o ChatGPT y un modelo local, y comprueba que las herramientas funcionan en los dos sin tocar el servidor. Si funcionan, has demostrado que lo que construiste es un activo independiente de cualquier proveedor. Si no, has encontrado el fallo antes de que te costara nada.
Pon una pasarela antes de escalar, no después. En cuanto más de un equipo usa más de un servidor, quieres un único punto para políticas, registro y auditoría. Añadir eso a posteriori en una docena de servidores desperdigados es de esas limpiezas que no le gustan a nadie.
Deja las acciones de escritura para el final, y acótalas bien. Leer los datos de un cliente tiene vuelta atrás; crear un reembolso o actualizar un registro, no. Cuando llegues ahí, dale a cada escritura su propio scope reducido y mantén a una persona aprobando cualquier cosa irreversible.
Construye este trimestre el camino de lectura para la consulta de clientes, detrás de tu IdP, y haz que funcione en dos proveedores. Ese solo ejercicio te enseña más sobre lo que vale MCP para tu empresa que cualquier cantidad de lectura, este artículo incluido.
Si prefieres no construir tú mismo el flujo de OAuth, el registro dinámico de clientes y el alojamiento de MCP, ChurroStack se encarga de esa capa por ti.