MCP en analítica: cómo lograr que un agente consulte tus métricas y no las invente

El Model Context Protocol (MCP) es un estándar abierto que permite a un modelo de lenguaje conectarse a una fuente de datos o herramienta externa y consultarla de forma estructurada. Aplicado a analítica, resuelve un problema concreto: en lugar de que un agente escriba SQL adivinando la lógica de tu negocio, consulta las métricas que tú ya definiste, con los permisos que ya configuraste.

La diferencia entre esas dos cosas es la diferencia entre una demo bonita y algo que puedes usar para decidir.

El problema que MCP resuelve

Cuando conectas un modelo directo a tu base de datos, le pides algo poco razonable: que infiera veinte años de reglas de negocio a partir de nombres de columnas.

Pregunta: “¿cuánto vendimos el trimestre pasado?”

El modelo tiene que decidir solo si “vendimos” es facturación o pedidos, si incluye cancelaciones, si el trimestre es fiscal o calendario, si suma impuestos, y qué hacer con las devoluciones registradas después del cierre. Toma cinco decisiones sin decírtelo, y devuelve un número con dos decimales y cero advertencias.

El resultado no es un error visible. Es un número plausible, y ese es exactamente el problema: nadie lo cuestiona.

Qué cambia con MCP

MCP invierte la relación. En lugar de exponer tablas crudas, expones un conjunto de herramientas y métricas definidas. El agente ya no improvisa: pide.

Sin MCP	Con MCP sobre capa semántica
El agente escribe SQL contra tablas	El agente solicita una métrica definida
La lógica de negocio se infiere	La lógica ya está en el modelo
Los permisos se pueden evadir	Los permisos se aplican en la consulta
Dos preguntas iguales pueden dar cifras distintas	La definición es única y estable
Imposible auditar cómo se calculó	Trazable al modelo

Ese renglón de permisos merece atención especial. Si tus reglas de acceso viven en la capa de presentación —en el tablero— un agente que consulta por debajo simplemente las rodea. Un director regional podría recibir cifras nacionales sin que nada falle visiblemente. Con los permisos aplicados en el modelo, el agente hereda exactamente las restricciones de la persona que pregunta.

Cómo se ve implementado

Omni expone su capa semántica a través de un MCP server. En la práctica eso significa que puedes conectar ChatGPT, Claude, un agente propio o cualquier cliente compatible, y que todos consulten las mismas métricas definidas.

El flujo de una pregunta:

1. Alguien pregunta en lenguaje natural, desde donde ya trabaja.
2. El cliente de IA descubre, vía MCP, qué métricas y dimensiones existen.
3. Solicita la métrica con los cortes que necesita.
4. La capa semántica resuelve la consulta aplicando lógica y permisos.
5. La respuesta regresa con una definición trazable detrás.

Lo relevante no es el paso 1, que es lo que se ve en los demos. Es el paso 4: hay una definición aprobada resolviendo la consulta, no una improvisación del modelo.

Qué necesitas antes de intentarlo

MCP no arregla datos desordenados. Solo los expone más rápido. Tres cosas tienen que estar en su lugar:

Datos centralizados. Si tu información vive en ocho sistemas que no se hablan, el agente solo verá el pedazo al que lo conectaste y responderá con una vista parcial sin avisarte. Esto se resuelve antes, con ingesta hacia una Data Cloud — la conversación de la AI-Ready Foundation.

Métricas definidas. Si no existe una definición única de tus indicadores principales, MCP no tiene qué exponer. Este es el trabajo de la capa semántica, y es donde se va la mayor parte del esfuerzo real de un proyecto de este tipo.

Permisos modelados. Antes de conectar nada, define quién puede ver qué a nivel de fila y de columna. Es mucho más incómodo descubrir un hueco después de que el agente ya está en manos de cien personas.

Qué esperar y qué no

Sí funciona bien: preguntas sobre métricas ya definidas, cortes por dimensiones existentes, comparativos entre periodos, seguimiento de un indicador y detección de un cambio brusco.

No funciona bien: preguntas que requieren una métrica que nadie modeló. Ahí el agente correctamente responde que no la tiene, y eso es una virtud, no un defecto. Es preferible un “no lo sé” a un número inventado. La consecuencia práctica es que el modelo semántico se convierte en algo vivo: cada pregunta que no se puede contestar es un candidato a modelar.

Lo que sorprende a los equipos: la parte de IA suele ser la más rápida de implementar. El trabajo está en ponerse de acuerdo internamente sobre qué significa cada métrica — y esa conversación es organizacional, no técnica.

Por dónde empezar

No arranques conectando IA a todo. Elige las cinco métricas de las que más se discute en las juntas de dirección, define esas cinco bien, exponlas vía MCP y deja que la dirección pregunte durante un mes.

Es un alcance pequeño y con una ventaja clara: si funciona, el argumento para seguir lo dan los propios usuarios. Y si en el camino descubres que las cinco métricas tenían tres definiciones cada una, acabas de encontrar el verdadero proyecto.

Si quieres ver cómo se vería en tu caso, platiquemos. También puedes leer sobre qué es una capa semántica si esa pieza todavía no está clara.