“El Model Context Protocol (MCP) es un estándar abierto diseñado para unificar la forma en que los modelos de Inteligencia Artificial (IA) se conectan con fuentes de datos, herramientas y aplicaciones externas. En términos sencillos, funciona como un conector universal para la IA, gracias a que proporciona un lenguaje único para que cualquier IA hable con cualquier sistema operativo, base de datos o software sin complicaciones”.

 

MCP Server a vista de pájaro

De acuerdo con nuestra experiencia de los últimos tres años, cuando una organización quería que un agente de IA consultara datos reales de sus fuentes de información, la solución rápida solía ser una API key compartida o una cuenta de servicio con más alcance del que a nadie le gustaría auditar después. Pero solía plantearse la misma pregunta incómoda: ¿con qué credencial va a entrar y cuánto alcance le estamos dando de más? Cada integración de un agente de IA con un sistema externo se construía de forma distinta, a menudo con accesos improvisados y difíciles de gobernar.

El propio Model Context Protocol (MCP) nació como un conector universal para resolver esta problemática.

Creado inicialmente por Anthropic en 2024 (los creadores de Claude) es, de facto, un estándar abierto que define cómo un agente de IA (cliente) se conecta a un sistema externo (servidor) para consultar datos o ejecutar funciones mediante un protocolo común en lugar de una integración a medida por cada combinación.

 

Qué es Sisense MCP Server, en pocas palabras

Sisense MCP Server es un endpoint alojado por Sisense que permite a cualquier agente de IA compatible con MCP (Model Context Protocol) —Claude, ChatGPT, Cursor— explorar los datos y construir gráficos a través de Sisense, no directamente contra la base de datos. El agente nunca verá las credenciales de acceso ni recibe una clave compartida: la conexión se autentica con OAuth 2.1 y cada solicitud se ejecuta de la misma forma que el usuario que inició la sesión, dentro de sus propios permisos y reglas de seguridad.

Dicho de otro modo: el agente trabaja contra el modelo semántico —las métricas, relaciones, reglas de seguridad— y no puede ver ni un dato al que tú mismo no tendrías acceso al acceder a la plataforma Sisense.

 

Qué puede hacer un agente conectado

Una vez establecida la conexión, el agente puede:

 

 

El matiz importante aquí es que el agente no inventa definiciones sobre la marcha: usa las mismas métricas y relaciones que ya gobiernan el resto de la organización.

 

Dos modelos de lenguaje, dos roles distintos

Vale la pena detenerse en un detalle que a menudo pasa desapercibido y que conviene explicar bien: en esta arquitectura conviven dos LLM distintos, cada uno con una función diferente.

El modelo de tu cliente de IA —el que corre dentro de Claude, ChatGPT o Cursor— es el que lleva la conversación y decide cuándo llamar a la herramienta de Sisense. Pero la traducción de esa petición en lenguaje natural hacia una consulta o un gráfico gobernado corre por cuenta de un segundo modelo, configurado del lado de Sisense y habilitado mediante Cloud-Linked Features. Esto es lo que garantiza que el resultado sea consistente con el modelo semántico y los permisos del usuario, sea cual sea el cliente de IA que se esté usando. Los servicios de descubrimiento (getDataSources, getDataSourceFields) solo leen metadatos y no requieren este segundo modelo; los servicios que generan consultas o gráficos (buildQuery, buildChart) sí lo necesitan.

 

Cómo funciona el flujo de autenticación

Tal y como se puede ver en esta ilustración, el flujo de autenticación funciona de la siguiente manera:

 

 

1. Se añade el endpoint del MCP Server de Sisense como servidor en el cliente de IA.
2. En el primer uso, el cliente redirige a un inicio de sesión OAuth 2.1 estándar contra Sisense, usando las credenciales existentes, SSO incluido.
3. Tras aprobar el acceso, Sisense emite al agente un token de corta duración, específica para ese usuario. El agente nunca ve la contraseña de Sisense ni una clave compartida.
4. Cada servicio que el agente invoca se ejecuta como lo harías tú, contra tu modelo de datos, filtrada por tus permisos.

No hay configuración de proveedor de identidad ni cuenta de servicio compartida. Al llegar a los datos únicamente a través de Sisense, la seguridad de datos, los permisos de fila y columna, y las definiciones del modelo se aplican automáticamente, sin trabajo adicional.

 

Seguridad y gobernanza: las piezas clave

Más que la novedad técnica, lo que hace interesante al MCP Server de Sisense para cualquier organización con datos sensibles es cómo resuelve el problema de seguridad y gobernanza:

• Sin credenciales compartidas. OAuth 2.1 con PKCE y credenciales de corta duración por usuario, que expiran automáticamente.
• Cada solicitud corre como el usuario conectado. Filtrada por sus roles y su seguridad de datos, es decir, los mismos permisos a nivel de fila y columna que ya tiene dentro de Sisense. Dos personas conectadas al mismo endpoint ven datos distintos, según lo que cada una tenga permitido ver.
• Trazabilidad completa. Cada solicitud queda vinculada a un usuario concreto y registrada, de modo que la actividad puede auditarse hasta una identidad específica.

Un punto que conviene destacar a cualquier responsable de seguridad: los resultados de una consulta aterrizan en el cliente de IA que se esté utilizando. Si el agente corre en ChatGPT, los resultados quedan en ChatGPT. Sisense es explícito al respecto: hay que tratar el cliente conectado como cualquier herramienta capaz de ver los datos de la organización, y conectar solo clientes de confianza.

 

Prerrequisitos y limitaciones actuales

Sisense MCP Server se puede utilizar en una instancia de Sisense en versión 2026.3.1 o posterior, y tener habilitado el MCP Server (viene activado por defecto y se controla en System Configuration > MCP), una cuenta de usuario con acceso a los modelos que se quieran explorar, y un cliente MCP compatible con servidores remotos sobre HTTP y OAuth —Claude, ChatGPT y Cursor están validados para esta Beta—. Para las herramientas con IA (buildQuery y buildChart) es necesario además tener Cloud-Linked Features activo y un proveedor de LLM configurado, ya sea el gestionado por Sisense (con cargo al paquete de créditos) o uno propio.

Sobre las limitaciones actuales, tres merecen una mención:

• Es de solo lectura. El agente explora datos y construye gráficos, pero no crea ni modifica modelos, dashboards ni contenido guardado en Sisense.
• Las sesiones se reautentican periódicamente. Al ser credenciales de corta duración, un agente de uso prolongado pedirá volver a iniciar sesión cuando expire.
• El renderizado interactivo depende del cliente. Si el cliente de IA no soporta contenido interactivo de MCP, recibirá solo un resumen narrativo del gráfico, no el gráfico renderizado.

 

Desde enero de 2026 hasta hoy: la evolución del MCP Server de Sisense

Vale la pena situar esta pieza en el tiempo, porque no ha llegado de la nada.

Sisense presentó el MCP Server en beta el 13 de enero de 2026, junto con el anuncio de disponibilidad general del Assistant y la apertura a opciones de LLM propio (BYO LLM) y a un servicio de LLM gestionado por Sisense. En ese primer anuncio, la compañía ya dejaba clara la intención de fondo: proporcionar a agentes externos como ChatGPT o Claude una vía para ayudar a construir gráficos, métricas y dashboards desde su propia interfaz.

Aquella primera versión, sin embargo, era deliberadamente modesta en su arquitectura de seguridad: un servidor local, que cada usuario levantaba en su propia máquina (o tras un túnel expuesto), autenticado con un único token de API compartido en variables de entorno. Funcional para explorar el concepto, pero poco defendible como despliegue de producción en una organización con control de accesos serio. El propio Sisense fue transparente sobre esto desde el principio, describiendo el MCP Server como una pieza con “una ruta de evolución clara, empezando por configuraciones independientes y avanzando hacia un servicio totalmente alojado con seguridad basada en OAuth 2.1”.

Esa ruta se ha cumplido en los meses siguientes: la guía de inicio rápido se trasladó al repositorio público de GitHub de Sisense en abril, señal de que el servidor local pasaba a tratarse como un proyecto abierto y no como el camino recomendado a largo plazo. Y en Q4, con la publicación de la versión 2026.3.1, Sisense culmina esa transición con el servidor alojado que hemos descrito: sin tokens compartidos, con OAuth 2.1 y PKCE, credenciales por usuario de corta duración, y gobernanza heredada automáticamente del propio Sisense. La documentación actual es explícita: este endpoint alojado sustituye al servidor local, y la recomendación para quien todavía lo use es migrar.

Ocho meses, en definitiva, para pasar de un prototipo de un solo token compartido a una arquitectura donde cada conexión respeta la identidad y los permisos de quien la abre. Es un ritmo de maduración que conviene tener en cuenta al evaluar cualquier capacidad “Beta” de Sisense: la primera versión suele ser una prueba de concepto deliberadamente simple, no el diseño final de seguridad.

 

La lectura de fondo

Sisense MCP Server no resuelve un problema de producto, resuelve un problema de arquitectura: cómo dejar que un agente conversacional sea útil sobre datos reales sin que eso implique renunciar a permisos, auditoría o gobernanza del modelo semántico.

Es la misma tensión que en Parapentex Studios llevamos varios meses analizando de cerca —incluida la arquitectura del propio MCP Server de Sisense a nivel técnico— porque es, probablemente, el punto donde más rápido va a evolucionar la analítica empresarial en los próximos trimestres: no en construir mejores dashboards, sino en decidir con qué reglas un agente puede llegar a ellos.

Se trata de poner en valor, con Sisense, todas nuestras investigaciones sobre la Inteligencia Activa.

¡Hablemos!

 

¿Listo para dar el salto a esta nueva generación de inteligencia empresarial? Hablemos, te mostraremos cómo es posible hacerlo realidad viendo Sisense en acción.

 

Parapentex Studios, September 2026