MCP: Conectando agentes de IA con sistemas empresariales

Todos los grandes sistemas empresariales —ERP, nóminas, RRHH, CRM— fueron diseñados para consultarse mediante una interfaz de usuario o una API. Era una decisión de diseño razonable para un mundo en el que los únicos consumidores de esos datos eran las personas. Se construía un panel, se formaba al equipo y se exportaba un informe cuando el director financiero hacía una pregunta. Funcionaba.

Ahora los agentes de IA también son consumidores. Necesitan leer los datos, razonar sobre ellos y actuar —en tiempo real, en lenguaje natural, dentro de una conversación. La interfaz no ha evolucionado al mismo ritmo. La mayoría de los sistemas empresariales siguen escondidos detrás de una interfaz que una IA no puede navegar, o detrás de una API que no fue diseñada pensando en la IA.

Model Context Protocol (MCP) es lo que cierra esa brecha. Es un estándar abierto que proporciona a los asistentes de IA una forma estructurada y consistente de descubrir qué puede hacer un sistema y llamarlo directamente. Nosotros lo hemos construido en producción. Este artículo explica qué significa eso en la práctica —para los sistemas que utilizas hoy y los clientes de IA que necesitarán comunicarse con ellos mañana.

El coste de integración del que nadie habla

Antes de MCP, conectar modelos de IA con sistemas empresariales implicaba escribir integraciones a medida —una por modelo, una por sistema. Si tienes cuatro sistemas y quieres conectarlos a tres clientes de IA (por ejemplo, Claude, ChatGPT y Microsoft Copilot), necesitas doce integraciones a medida. Cada una requiere su propio prompt engineering, su propio wrapper de API y su propio mantenimiento. Añade un sistema nuevo, añade N integraciones más. Añade un cliente de IA nuevo, añade M más.

El sector ha empezado a llamar a MCP «USB-C for AI» —la analogía procede de BCG — que acuñó la expresión, y es precisa. Antes del USB-C, cada dispositivo tenía su propio puerto. Antes de MCP, cada par IA-sistema necesitaba su propio conector. MCP reduce el problema N×M a N+M: construye un servidor MCP por sistema, y cualquier cliente de IA compatible puede conectarse a él. No es una afirmación de marketing —es una propiedad arquitectónica del protocolo.

Qué cambia cuando tu sistema tiene una interfaz MCP

La forma más sencilla de entender el valor es a través de lo que se vuelve posible, no de cómo funciona. Cuando un sistema tiene un servidor MCP, un asistente de IA puede responder preguntas sobre datos de producción en tiempo real en un único intercambio en lenguaje natural —sin SQL, sin exportaciones de BI, sin cambiar de pestaña.

Construimos un servidor MCP para una plataforma de nóminas y RRHH multitenant. Esto es lo que significa en la práctica:

Este no es un entorno de demostración con datos sintéticos. Son consultas reales contra un sistema de producción en vivo, ejecutadas a través de MCP. Y el patrón se generaliza —inventario de ERP, pipeline de CRM, gestión de proyectos, logística. Cualquier sistema con datos estructurados puede tener esta interfaz. Las preguntas cambian; la arquitectura, no.

Conversaciones reales, datos reales

A continuación se muestran dos capturas de pantalla de sesiones reales con la integración MCP activada. No son mockups. El asistente de IA no tiene un front-end personalizado —se comunica directamente con el sistema de nóminas a través de MCP, lee datos en tiempo real y devuelve las respuestas en el mismo hilo conversacional.

Una verificación de cumplimiento —identificando ausencias de nómina en el mes en curso— resuelta con una única pregunta en lenguaje natural sobre datos de producción en tiempo real.

Análisis de la evolución del coste para el empleador en los últimos 6 meses, extraído de datos en tiempo real y devuelto en la conversación —sin panel ni exportación de BI.

Por qué esto es diferente a usar simplemente una API

Si ya tienes APIs, esta es la pregunta natural. Las APIs son bien conocidas, están ampliamente desplegadas y tus equipos saben cómo construirlas. ¿Para qué añadir otra capa?

La diferencia está en quién —o qué— las llama. Las APIs fueron diseñadas para código que sabe exactamente qué llamar y cuándo. MCP está diseñado para modelos de IA que necesitan averiguarlo por sí mismos. Algunas diferencias concretas que importan en la práctica:

• ✓
  Cualquier host compatible con MCP puede conectarse — la portabilidad es el objetivo.

  ChatGPT, Claude, VS Code Copilot y otros son compatibles con MCP de forma nativa. Cada host tiene su propia UX, controles de seguridad y modelo de entitlements — eso es real, y tu servidor MCP debe tenerlo en cuenta. El servidor se construye una vez; los clientes son tu elección.

• ✓
  Sesiones con estado y autenticación estructurada.

  MCP admite sesiones con estado (los transportes Streamable HTTP pueden asignar un ID de sesión que los clientes mantienen en peticiones sucesivas) y define un flujo de autorización basado en OAuth para despliegues HTTP. El host sigue controlando qué contexto se comparte y cuándo se invocan las herramientas — MCP proporciona la superficie estructurada; tu servidor gobierna los límites.

• ✓
  El descubrimiento de herramientas es dinámico.

  La IA aprende qué herramientas están disponibles en tiempo de ejecución mediante negociación de capacidades durante la inicialización. Las nuevas capacidades quedan disponibles para todos los clientes conectados sin cambios de código en el lado del cliente.

• ✓
  El modelo decide cuándo usar una herramienta.

  Describes qué hace cada capacidad. El modelo razona sobre cuándo llamarla, en qué orden y con qué parámetros. Esto es cualitativamente diferente de una secuencia de llamadas a la API que hayas codificado de antemano — se adapta a la pregunta que se formula.

Una API le da a una máquina una puerta. MCP le da a una IA el plano del edificio, las llaves y el criterio para moverse por él.

Los paneles solo eran el principio

Durante tres décadas, las empresas han consumido sus datos operativos a través de informes y paneles. Esas herramientas fueron diseñadas para personas que navegan por interfaces, ejecutan consultas programadas y comparten exportaciones estáticas. Responden a «qué ha ocurrido». No responden al «por qué» ni a «qué debería hacer al respecto».

Las interfaces conversacionales responden a las tres. Y son accesibles para todos en la empresa —no solo para el analista que sabe construir un informe o el ingeniero que puede escribir la consulta. Cuando los datos residen detrás de un servidor MCP, la pregunta se convierte en la interfaz.

Esto no es una predicción sobre un futuro lejano. Block ha documentado el despliegue de integraciones MCP a escala de empresa en cuestión de semanas. La gobernanza de MCP ha pasado a la Agentic AI Foundation de la Linux Foundation —con respaldo amplio del sector, incluido Bloomberg—, lo que confirma que esto es infraestructura, no una tendencia pasajera. Gartner estima que el 40 % de las aplicaciones empresariales estarán integradas con agentes de IA especializados a finales de 2026 —frente a menos del 5 % actual—, con sistemas de IA que actúan en nombre de los usuarios, no solo les responden. La pregunta no es si este cambio se produce. Es si tus sistemas estarán preparados cuando llegue.

Un servidor MCP es la forma de preparar tus sistemas para la IA. Una vez que existe, cualquier nuevo cliente de IA —actual o futuro— se conecta a él sin configuración adicional. No estás construyendo para una integración. Estás construyendo la infraestructura que utilizarán todas las integraciones.

Lo que realmente se necesita para construir esto en producción

Una demo de MCP funcional no es una integración MCP en producción. La brecha entre ambas es donde ocurre la mayor parte del trabajo de ingeniería. Algunas situaciones con las que nos encontramos y que cualquiera que construya esto en serio deberá afrontar: la minimización y seudonimización de datos deben integrarse en el diseño desde el principio: los identificadores sensibles se resuelven en el lado del servidor, bajo RBAC y auditoría, antes de que ningún dato llegue al contexto de la IA. MCP define dos modos de transporte: stdio para servidores locales y Streamable HTTP para despliegues remotos. En la práctica, las pasarelas de API que no gestionan bien el streaming se convierten en el principal cuello de botella —lo descubrimos con un objetivo de despliegue específico y tuvimos que diseñar una solución alternativa. Y los modelos de IA no siempre utilizan el contexto que les proporcionas exactamente como esperas —la resiliencia en producción implica gestionar comportamientos del modelo que se desvían del caso ideal.

La especificación MCP es inusualmente directa sobre lo que está en juego: señala explícitamente que MCP puede habilitar rutas de acceso arbitrario a datos y ejecución de código, y deposita en el implementador la responsabilidad sobre el consentimiento, la seguridad de las herramientas, la privacidad y la auditoría. Nosotros lo tratamos como diseño de infraestructura, no como algo secundario. Cada herramienta que exponemos pasa por una clasificación de riesgo según estas cuatro dimensiones antes de llegar a producción.

Un ejemplo concreto del problema de fragmentación de clientes: entregar un documento PDF a través de MCP. Un enfoque basado en URI de archivo local funciona perfectamente en herramientas de desarrollo como VS Code. Falla por completo en Claude.ai web y ChatGPT, que se ejecutan en contextos de navegador con sandbox que no pueden acceder al sistema de archivos local. Resolver esto requirió un mecanismo de entrega diferente que funcione en todos los clientes —no solo en el primero contra el que se prueba. La fragmentación de clientes MCP es real y requiere decisiones de diseño deliberadas, en lugar de asumir que el primer enfoque que funciona es el portable.

La integración que entregamos cubre una pila OAuth completa, un modelo de permisos multitenant y más de 230 tests. Funciona en VS Code Copilot, Claude Desktop, Claude.ai web y ChatGPT. Sabemos cuáles son las partes difíciles porque las hemos construido.

WantedForCode puede construir esto para tu sistema

Hemos construido una integración MCP en producción para una plataforma de nóminas y RRHH multitenant. Conocemos la arquitectura, las decisiones de seguridad, las restricciones de despliegue y cómo hacer que el mismo servidor funcione de forma fiable en distintos clientes de IA. Ese conocimiento se traslada directamente a otros sistemas.

Si tu plataforma tiene datos a los que tu equipo, tus clientes o tus agentes de IA deberían poder acceder mediante conversación —podemos construir la integración. No es una capacidad que estemos proponiendo en teoría. Es algo que ya hemos entregado. Si estás evaluando si invertir en MCP para tu sistema, empieza por entender cómo son tus datos y qué consultas necesitan realmente responder tus usuarios. Por ahí empezamos nosotros también.

La infraestructura que querrás haber construido antes

Las empresas que avanzan más rápido con la IA en este momento son aquellas cuyos sistemas ya estaban preparados cuando llegó la necesidad. Un servidor MCP es infraestructura en ese sentido —no hace nada visible por sí solo, pero es lo que permite que cualquier cliente de IA que llegue después funcione sin esfuerzo de integración adicional.

Las empresas que no lo tengan llevarán años construyendo integraciones N×M —una por modelo, una por sistema, mientras el panorama de la IA sigue fragmentándose. Las que sí lo tengan conectarán nuevos clientes en días. Esa es la ventaja acumulativa de construir la abstracción correcta una vez, en lugar de construir conectores indefinidamente.

En dos semanas:

• ✓
  Semana 1

  Mapear tus casos de uso principales en una superficie de herramientas MCP. Definir scopes, modelo de tenencia y límites de autenticación. Identificar las clases de riesgo de cada herramienta (acceso a datos, ejecución de código, exposición de privacidad).

• ✓
  Semana 2

  Servidor prototipo funcional. Plan de despliegue en ChatGPT, Claude y Copilot. Registro de riesgos y plan de auditoría. Sin presentaciones — un roadmap de implementación real.

Hablemos.