Para implementar MCP y APIs sobre tu modelo semántico eliges entre cinco patrones (Fabric Data Agent MCP, Power BI Remote MCP, Power BI Local MCP, API propia y MCP propio sobre API) según cuánto control, semántica y experiencia conversacional necesites. En todos, primero validas permisos, tenant, token y auditoría; luego ejecutas una consulta real y comparas la respuesta con métricas conocidas. Un endpoint que responde status: ok demuestra disponibilidad, no que el negocio pueda confiar en él.¿Qué son realmente MCP y APIs sobre el modelo semántico?
Cuando el negocio quiere leer sus datos desde Claude, Codex u otros agentes, la tentación es tratar cualquier endpoint como una puerta abierta. No lo es. MCP y APIs son contratos de consumo, no atajos para evitar el gobierno. Definen qué métricas se pueden pedir, con qué filtros, quién tiene permiso y cómo queda registrada cada consulta, la misma lógica que explicamos al detallar qué permite MCP en Power BI y Fabric y cómo gobernarlo.
El modelo semántico es el acuerdo sobre el que dirección y equipo leen los mismos números. Exponerlo a un agente de IA no cambia esa idea, la extiende. Un agente conectado a un modelo débil solo produce respuestas débiles con más velocidad, y ese es justamente el eje de cómo funciona un agente de datos de Fabric sobre un modelo semántico. Por eso el orden importa: primero ordenas métricas y decisiones, después eliges la ruta de consumo.
¿Cuáles son los cinco patrones para conectar agentes a tus datos?
La elección depende de cuánto control, semántica y experiencia conversacional necesita el cliente. Estos son los patrones documentados y cuándo conviene cada uno:
- Fabric Data Agent MCP: cuando quieres un agente propio del negocio, con instrucciones y una fuente gobernada. Es el caso de uso más cerrado y ejecutivo.
- Power BI Remote MCP: para consulta conversacional, análisis y hallazgos sobre modelos semánticos que ya existen.
- Power BI Local MCP: para desarrollo y administración de modelos en Power BI Desktop, workspaces de Microsoft Fabric o proyectos PBIP/TMDL.
- API propia: cuando un producto o una automatización necesita respuestas estables, versionadas y auditables.
- MCP propio sobre API: cuando un cliente agéntico externo debe usar herramientas de negocio controladas por ti o por el cliente.
¿Cómo se comparan los patrones y qué validas en cada uno?
Cada patrón exige una validación mínima antes de ponerlo frente a un cliente. Esta tabla resume el criterio:
| Patrón | Cuándo usarlo | Validación mínima |
|---|---|---|
| Fabric Data Agent MCP | Agente propio con fuente gobernada | Endpoint del Data Agent, OAuth, una llamada a herramienta y pregunta ejecutiva con métricas conocidas |
| Power BI Remote MCP | Consulta y análisis sobre modelos existentes | Permisos del usuario, modelo correcto, preguntas de control y comparación con medidas conocidas |
| Power BI Local MCP | Desarrollo y administración de modelos | Menor privilegio, diferencias revisables, transacción controlada y validación DAX tras cada cambio estructural |
| API propia | Producto o automatización estable | Lista permitida de medidas, filtros obligatorios, registros, pruebas de autorización y límites de consulta |
| MCP propio sobre API | Cliente agéntico externo | Herramientas específicas por caso, descripciones precisas, errores claros y una prueba por flujo |
La lógica es la misma en todos: acotar el privilegio, hacer revisable el cambio y comparar contra una verdad conocida.
¿Por qué un endpoint MCP no es una API REST abierta?
Es el malentendido más caro. El endpoint de 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, con las operaciones initialize, tools/list y tools/call. No es una URL que golpeas con una petición REST cualquiera.
Además no admite el registro dinámico de clientes: cada solicitud necesita un token de Fabric obtenido mediante el flujo de autenticación del cliente. Y hay un detalle que separa a los equipos serios del resto: si el endpoint solo responde status: ok, todavía falta probar una llamada real. Disponible no significa validado.
¿Qué pasos sigues para implementar y validar antes de exponerlo?
Antes de conectar cualquier agente a datos de negocio, recorre esta secuencia:
- Confirma que el modelo semántico es correcto: las medidas ya son la única verdad, no una aproximación.
- Elige el patrón según control, semántica y experiencia conversacional que necesita el caso.
- Valida el gobierno: RBAC, tenant, token de Fabric, cumplimiento, auditoría, menor privilegio y límites por usuario.
- Inicializa el cliente y lista las herramientas disponibles (
initialize,tools/list). - Ejecuta una consulta real (
tools/call) con una pregunta cuya respuesta ya conoces. - Compara la respuesta con métricas conocidas. Si no coincide, el modelo, los permisos o el filtro fallan, no el agente.
Este ciclo es la diferencia entre una demo y un producto que dirección puede usar sin discutir cifras.
¿Preview o producción? Cuándo un MCP no reemplaza una API gobernada
Power BI MCP y Data Agent MCP siguen en versión preliminar. El servidor remoto consulta modelos; el local también puede modificar metadatos y modelos, así que su superficie de riesgo es mayor. La documentación de servidores MCP de Fabric distingue el servidor remoto Fabric Core, en versión preliminar, del servidor local de código abierto pensado para desarrollo.
Un endpoint MCP en preview es excelente para explorar y conversar con los datos, pero no reemplaza una API gobernada cuando el producto necesita respuestas versionadas y estables. Si tu automatización factura, decide precios o alimenta a un cliente externo, la API propia con lista permitida de medidas y registros suele ser la ruta correcta. El patrón se elige por el nivel de garantía que el negocio necesita, no por lo nuevo que sea.
Siguiente paso
Exponer el modelo semántico a agentes de IA solo funciona cuando el modelo ya es un contrato confiable y el gobierno está resuelto. Esa base se construye con criterio antes que con herramienta, sea por la vía de la formación o de la consultoría. Si quieres ver cómo luce en la práctica y evaluar el punto de partida de tu empresa antes de conectar cualquier agente a datos productivos, mira la demo gratuita.
Preguntas relacionadas
¿MCP reemplaza a una API para consultar el modelo semántico?
No siempre. Un endpoint MCP es ideal para consulta conversacional y análisis, pero cuando un producto necesita respuestas versionadas, estables y auditables suele convenir una API propia con lista permitida de medidas, filtros obligatorios y registros. El patrón se elige por el nivel de garantía que el negocio requiere.
¿Qué significa que un endpoint responda status: ok?
Solo demuestra disponibilidad, no validación de negocio. Para confiar en él debes inicializar el cliente, listar las herramientas, ejecutar una consulta real y comparar la respuesta con métricas conocidas. Disponible no significa validado.
¿Por qué el endpoint de Fabric Data Agent no se usa como una API REST?
Porque, aunque tiene una URL, se consume mediante el protocolo MCP con las operaciones initialize, tools/list y tools/call. No admite registro dinámico de clientes y cada solicitud necesita un token de Fabric obtenido por el flujo de autenticación del cliente.
¿Qué debo validar antes de exponer un modelo semántico a un agente de IA?
RBAC, el tenant, el token de Fabric, el cumplimiento, la auditoría, el menor privilegio y los límites por usuario. Power BI MCP y Data Agent MCP siguen en versión preliminar, así que estas validaciones son obligatorias antes de usarlos con un cliente.
¿Qué diferencia hay entre el Power BI Remote MCP y el Local MCP?
El servidor remoto consulta modelos semánticos existentes para análisis y hallazgos. El local, orientado a desarrollo, también puede modificar metadatos y modelos en Power BI Desktop, workspaces de Fabric o proyectos PBIP/TMDL, por lo que exige menor privilegio y validación DAX después de cada cambio estructural.