MCP es un protocolo para que un agente consuma datos a través de herramientas declaradas. No mejora la calidad del modelo ni el gobierno: solo hace consultable lo que ya existe. Si el modelo semántico está pobre, el agente amplifica ese problema con más alcance.
Cuando el negocio quiere leer sus datos desde Claude, Codex u otro cliente agéntico, aparece el Model Context Protocol (MCP). Es tentador tratarlo como una API abierta que resuelve todo, pero es un contrato de consumo con reglas propias de autenticación, permisos y auditoría. Esta guía separa dos cosas que suelen confundirse: qué permite el protocolo y qué garantiza la calidad del dato. Son planos distintos, y mezclarlos es la fuente de casi todos los errores.
El protocolo no es lo mismo que la calidad del dato
Un endpoint MCP describe cómo un cliente descubre y ejecuta herramientas: initialize para abrir sesión, tools/list para ver qué puede hacer y tools/call para ejecutar. Eso es todo lo que el protocolo garantiza. No dice nada sobre si las medidas están certificadas, si las relaciones están limpias o si el vocabulario de negocio es correcto.
Esa distinción importa porque un agente sobre un modelo desordenado responde con la misma seguridad que uno sobre un modelo bien gobernado. La diferencia solo se ve al comparar contra métricas conocidas. Por eso el trabajo previo, nombres de negocio, medidas certificadas, sinónimos y columnas técnicas ocultas, no es opcional: es lo que hace que la respuesta sea confiable. El mismo principio que sostiene a un agente de datos sobre un modelo semántico gobernado aplica aquí, con la diferencia de que MCP abre ese consumo a clientes externos.
Qué rutas MCP existen para Power BI y Fabric
No hay una sola forma de conectar un agente. La documentación de servidores MCP de Microsoft distingue varias, y cada una tiene un propósito y un nivel de riesgo diferente.
- Fabric Data Agent MCP: para cuando el negocio ya publicó un Data Agent propio, con instrucciones y una fuente gobernada. El agente acota el dominio e interpreta preguntas dentro del contrato.
- Power BI Remote MCP: para consulta conversacional, análisis y hallazgos sobre modelos semánticos existentes. Solo lectura.
- Power BI Local MCP: para desarrollo y administración en Power BI Desktop, workspaces de Fabric o proyectos PBIP/TMDL. Este también puede modificar metadatos y modelos, no solo leerlos.
La decisión depende de cuánto control y semántica necesita el cliente. Un consumo de solo lectura para responder preguntas ejecutivas no requiere lo mismo que un flujo de desarrollo que altera estructura. Mezclar ambos bajo la misma configuración de permisos es un error frecuente.
Autenticación: un endpoint MCP no es una API REST abierta
El endpoint de un Fabric Data Agent sigue el formato https://api.fabric.microsoft.com/v1/mcp/workspaces/{workspaceId}/dataagents/{dataAgentId}/agent, pero se consume mediante el protocolo MCP, no con llamadas REST directas. Un detalle que cambia el diseño: no admite registro dinámico de clientes. Cada solicitud necesita un token de Fabric obtenido con el flujo de autenticación del propio cliente.
Esto significa que la identidad y los permisos viajan con el usuario o la aplicación que llama, no con un secreto compartido genérico. Antes de habilitar cualquier ruta conviene validar el RBAC, el tenant, el token de Fabric y los límites por usuario. La documentación de Fabric sobre el servidor MCP del Data Agent detalla que el agente opera en solo lectura y respeta permisos del usuario y políticas de Purview, lo que ancla la autorización en la plataforma en lugar de dejarla al cliente.
Qué herramientas se exponen y cómo instruir al agente
El protocolo expone herramientas, y esas herramientas son la superficie real de lo que el agente puede hacer. En un Data Agent bien preparado, las instrucciones base marcan los límites: responder en el idioma del usuario, usar solo medidas y fuentes aprobadas, declarar período y filtros, no inventar KPIs, explicar límites de confianza y pedir aclaración cuando falte contexto.
Ese encuadre evita que el agente suene como un diccionario de tablas y lo obliga a ayudar a decidir sin salirse del contrato semántico. Cuando en cambio se expone una API propia o un MCP propio sobre esa API, el control es más explícito todavía: lista permitida de medidas, filtros obligatorios, registros de uso, pruebas de autorización y límites de consulta. Cada herramienta debe tener una descripción precisa y errores claros, porque el agente decide qué llamar leyendo esas descripciones.
Disponible no significa validado
Aquí está el error más caro. Un endpoint que responde status: ok solo demuestra que está disponible, no que funcione para el negocio. Power BI MCP y Data Agent MCP siguen en versión preliminar según Microsoft, y una preview disponible no equivale a una integración validada.
La validación de negocio exige cuatro pasos concretos: inicializar el cliente, listar las herramientas, ejecutar una consulta real y comparar la respuesta con métricas ya conocidas. Recién ahí se sabe si el agente responde lo que el negocio espera. Saltarse esa comparación es abrir una puerta sin saber a dónde da. Para lecturas por usuario, la validación se cruza además con las reglas de seguridad a nivel de fila del modelo, porque MCP hereda esos permisos pero no los inventa.
Cuándo MCP no es la respuesta
MCP brilla para consumo conversacional y exploratorio desde clientes agénticos. No es la mejor opción cuando el producto necesita respuestas estables, versionadas y auditables. Para ese caso, una API propia gobernada, con contratos explícitos y versionado, ofrece garantías que un endpoint en preview no da todavía.
La regla práctica: si un humano hace preguntas y evalúa el contexto, MCP con permisos correctos es un buen encaje. Si un sistema depende de una respuesta idéntica cada vez, conviene una API con lista permitida de medidas y límites duros. Estas rutas no compiten, se complementan, y elegir la equivocada cuesta reelaborar la integración entera.
Qué hacer antes de conectar el primer cliente
Antes de dar acceso MCP a Claude, Codex o VS Code sobre datos reales, corre una prueba de habilitación de extremo a extremo con un único usuario acotado: inicializa el cliente, lista las herramientas, ejecuta una pregunta cuya respuesta ya conoces y compara el resultado contra la medida certificada. Documenta el RBAC, el tenant, el token de Fabric y el menor privilegio de ese usuario antes de ampliar el acceso. Y verifica siempre la documentación vigente de Microsoft: las capacidades descritas evolucionan y conviene confirmar su estado de disponibilidad antes de operar.
Si tu empresa está evaluando cómo conectar agentes a sus datos con permisos, auditoría y un modelo semántico confiable detrás, mira la demo gratuita y conoce cómo abordamos ese diagnóstico y su implementación.
Preguntas relacionadas
¿MCP reemplaza a una API REST para exponer datos?
No. Un endpoint MCP se consume con el protocolo MCP (initialize, tools/list, tools/call), no con llamadas REST directas, y no admite registro dinámico de clientes. Cuando el producto necesita respuestas versionadas, estables y auditables, una API propia gobernada sigue siendo la opción adecuada.
¿Qué token necesita cada llamada a un Fabric Data Agent por MCP?
Cada solicitud requiere un token de Fabric obtenido mediante el flujo de autenticación del propio cliente. No se usa un secreto compartido genérico: la identidad y los permisos del usuario viajan en cada llamada y la plataforma aplica RBAC y políticas de Purview.
¿Por qué un endpoint que responde OK no está listo para producción?
Porque el estado OK solo prueba disponibilidad. La validación de negocio exige inicializar el cliente, listar herramientas, ejecutar una consulta real y comparar la respuesta con métricas conocidas. Sin esa comparación no se sabe si el agente responde lo que el negocio espera.
¿Cuál es la diferencia entre el servidor MCP remoto y el local de Power BI?
El servidor remoto consulta modelos semánticos en solo lectura. El local, orientado a desarrollo en Power BI Desktop, workspaces de Fabric o proyectos PBIP/TMDL, también puede modificar metadatos y modelos. Por eso el local exige menor privilegio y validación DAX después de cada cambio estructural.
¿MCP mejora la calidad de mis datos o de mis métricas?
No. MCP es un contrato de consumo: hace consultable lo que ya existe. Si el modelo semántico tiene medidas sin certificar o relaciones sucias, el agente amplifica ese problema con más alcance. La calidad se resuelve antes, en el modelo, no en el protocolo.