The Power BI app provides read/write access to the Microsoft Power BI REST API (v1.0) through its official endpoints. It can be consumed two ways: as a remote MCP server that Agent Factory agents call as tools, or as a Builder app whose instructions you call directly from DSUL. The MCP surface groups every operation into eleven entity tools (workspaces, datasets, query, refresh, reports, dashboards, dataflows, gateways, imports, capacities, admin), each driven by an action argument, and runs in the tenant app-instance context (it resolves the installing workspace’s own credentials and authorizes the calling agent against a per-workspace allowlist). Authentication is per-user OAuth2 authorization-code with PKCE against Microsoft Entra ID: each end user signs in with their own Microsoft account, so every call runs with that user’s Power BI permissions.
DAX & semantic models
Reports & dashboards
Workspaces & admin
Who is this for?
This connector is used by three different roles. Jump to the section that matches yours; each one is self-contained.Agent builder
Platform admin
Workspace builder
Prerequisites
- A Microsoft Power BI account (Power BI Pro / Premium Per User, or access to a Premium / Fabric capacity for paginated exports and the admin APIs).
- A Microsoft Entra ID (formerly Azure AD) tenant where you can register an OAuth application, done in the Microsoft Entra admin center under App registrations.
- The application must request delegated Power BI service permissions; the connector requests this default scope set:
- For tenant-wide admin operations (
admintool), the connected user must be a Fabric / Power BI administrator, and the Power BI tenant settings must allow service-principal / API access where applicable. - To run DAX queries, the “Dataset Execute Queries REST API” must be enabled in the Power BI tenant settings.
Platform admin (Governance): one-time platform setup
Platform admin (Governance): one-time platform setup
1. Configure the connector
Register the OAuth application in Microsoft Entra ID
https://api.studio.prisme.ai/v2/workspaces/slug:powerbi/webhooks/oauthCallback on production). Under API permissions, add the Power BI Service delegated permissions matching the scopes in Prerequisites, then create a client secret. Save the Application (client) ID, the client secret and the directory (tenant) ID.Enter the credentials through the configuration app
powerbi workspace and launch its Configuration app: <studio>/apps/powerbi (e.g. https://studio.prisme.ai/apps/powerbi), also linked as Configuration app on the installed instance. Follow the in-app instructions to paste the client ID, client secret and tenant; the app stores them in the workspace’s secrets for you. Do not edit Studio’s raw Secrets by hand.Tell workspaces to connect
2. Declare the capability in AI Governance
Generic connectors (broad tool surfaces meant to be shared across many agents, like Power BI) are best exposed as a named capability in AI Governance. Agent builders then enable that capability on their agents instead of pasting a raw MCP endpoint.Open AI Governance > Capabilities
Point it at the MCP endpoint
agent_id in the scope is what lets the connector identify and authorize the calling agent.Make it available to agent builders
Smoke-test
- Agent builder (Agent Factory)
- Workspace builder (DSUL)
Agent builder
Goal: let an agent you build in Agent Factory query and manage Power BI through MCP tools.agent_id that Agent Factory injects through the capability Scope, and that agent must appear in the connector’s authorized-agents allowlist (managed in the configuration app). The Power BI access token itself is resolved server-side from the connected user’s OAuth session.There are two ways to wire it up. Pick based on how much isolation you need.Option A: Enable the shared capability from the catalog
The fastest path: a Platform admin (or a workspace owner via the config app’s one-click Add to catalog button) has already published a Power BI capability to your organization’s catalog, so you just pick it.Open your agent in Agent Factory
Add the Power BI capability
context_id,agent_id,user_id) are already wired: nothing to paste, and the shared instance accepts every agent granted the capability, so there is no allowlist step on your side.Connect a Microsoft account
connect_url. Subsequent calls reuse the stored token.Option B: Run it from your own workspace (recommended)
For production agents, install the connector in your own workspace and point the agent at that workspace’s MCP endpoint.Install and configure the connector in your workspace
Allowlist your agent
Add the MCP capability to your agent
agent_id is what lets the connector identify and authorize your agent; without it, every call is rejected with an explicit “agent could not be identified” message. This Scope is separate from the Microsoft OAuth scopes.Connect a Microsoft account
Brief the agent in its system prompt
Whichever option you pick, wiring the capability is not enough: the agent must know the MCP exists and when to use it. Copy-pasteable starter:agent_id..default scope, so the issued token inherits exactly the permissions granted to the Microsoft Entra app registration; it never forces write access. To allow only read access, grant the app only read-level Power BI Service delegated permissions (e.g. Dataset.Read.All, Report.Read.All, Dashboard.Read.All, Workspace.Read.All) instead of their *.ReadWrite.All variants. The connection still succeeds (the connection check is a read); any write call is then rejected by Power BI with 403 Forbidden, surfaced to the agent as an error. This restriction lives on the Entra app, outside any tenant’s reach, a hard guarantee.Available Tools
Each tool takes anaction argument selecting the concrete operation, plus the per-action parameters. groupId (the workspace id) is optional on most data tools; empty means “My workspace”.Output Formats
Every tool accepts anoutputFormat argument that controls the MCP response shape:verbose(default): human-readable text optimized for LLM consumptionstructured: machine-readable JSON instructuredContentboth: verbose text plus the structured payload
Tool Details
query
datasets
getTables works only for Push-API datasets. On a normal import / DirectQuery semantic model use getSchema (column schema via DAX), or the query tool with EVALUATE INFO.VIEW.TABLES() / EVALUATE INFO.VIEW.COLUMNS().refresh
reports
dashboards
admin
admin actions require the connected user to be a Fabric / Power BI administrator; otherwise the provider returns 401 / 403.Error Handling
Common Issues
“This agent is not authorized to use this connector”: The calling agent is not in the allowlist. Open the configuration app → Authorized agents → tick this agent (or enable Allow all agents) and Save. “The calling agent could not be identified”: The MCP capability Scope does not declareagent_id, so Agent Factory never injects the agent identity. Set the Scope to context_id,agent_id,user_id on the capability, then allow the agent in the config app.
“Power BI is not connected for this user”: No per-user OAuth token. Open the configuration app and click Connexion, or use the agent’s connect flow.
“Power BI token refresh failed … must reconnect”: The stored refresh token was revoked or expired (Microsoft Entra ID invalidated it). The connection is dropped automatically; the user must reconnect from the config app.
“Power BI OAuth is not configured”: The Microsoft Entra ID client ID/secret/tenant is missing. Open the configuration app and enter the OAuth credentials (or ask the platform admin to register the central application).
getTables fails with “not Push API dataset”: getTables only works on Push-API datasets. To inspect a normal import / DirectQuery semantic model, use the datasets getSchema action, or run a DAX query such as EVALUATE INFO.VIEW.TABLES() / EVALUATE INFO.VIEW.COLUMNS() via the query tool.