Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MCP Server for Power BI list my Power BI workspaces"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Model Context Protocol (MCP) server for exploring Microsoft Fabric / Power BI workspaces and semantic models, and for executing ad‑hoc DAX queries.
🔐 OAuth/Entra ID support. Integrates with LibreChat and other OAuth-enabled clients, with a choice of On-Behalf-Of or custody authentication.
Related MCP server: PowerBI MCP Server
Tool | Purpose |
| List workspaces the signed-in user can access. |
| Get the workspace ID for a given workspace name. |
| Enumerate datasets in a workspace. |
| Retrieve dataset (semantic model) metadata and structure via DAX introspection |
| Run a DAX query against a dataset using the Execute Queries API. |
Full Entra ID/Azure AD authentication
JWT token validation with JWKS
On-Behalf-Of or custody authentication for Power BI access
Role and scope-based authorization
Claims challenge support for conditional access
Perfect for LibreChat integration
Simple bearer token authentication
Direct Power BI API access
Suitable for local testing with MCP clients
Python 3.12+
uv (fast Python package/project manager)
For HTTP mode: Azure AD app registrations with OAuth configured
For STDIO mode: Power BI access token
This project uses Ruff for linting and formatting, ty for type checking, and pytest for tests.
Install development dependencies:
uv sync --locked --extra devRun the checks CI runs:
uv run ruff check .
uv run ruff format --check .
uv run ty check
uv run pytestuv.lock is tracked. It names the exact version of everything that goes into a
release, so a build from a given commit installs what that commit was tested
with — the container build and CI both use it, and both fail rather than
re-resolve if it has drifted from pyproject.toml.
Upgrading is therefore a deliberate commit:
uv lock --upgrade # or: uv lock --upgrade-package <name>
uv sync --extra devThen run the checks above before committing the new uv.lock. ty and ruff
are pinned exactly in pyproject.toml because both are pre-1.0 and change what
they accept between releases; moving either should be its own change, with
whatever code it newly objects to fixed alongside.
Install dependencies:
uv syncConfigure environment (copy .env.example):
# Azure AD Configuration
PORT=3001
TENANT_ID=your-tenant-id
AUDIENCE=your-api-app-id
# Authentication mode: obo or custody
AUTH_MODE=obo
ENTRA_CLIENT_ID=your-client-id
ENTRA_CLIENT_SECRET=your-client-secret
# Authorization
REQUIRED_SCOPES=mcp.access
REQUIRED_ROLES=mcp.user
# Logging
LOG_LEVEL=infoRun the server:
python -m mcp_for_powerbi.server_httpServer starts on http://localhost:3001/mcp
Note: STDIO mode now requires OAuth integration. The server expects the Authorization header to be passed via the MCP client.
Run the server:
uv run mcp-for-powerbiBoth HTTP and STDIO modes use Entra ID OAuth2 with:
JWT Validation: Verifies token signature, audience, issuer
Authorization: Validates roles and scopes
AUTH_MODE selects how the server obtains a token for the Power BI API. The
server will not choose for you: an unrecognised mode, or one whose prerequisites
are missing, stops it at startup.
Mode | How the Power BI token is obtained | Holds credentials? |
| On-Behalf-Of exchange of the caller's token | No |
| The server brokers the user's sign-in and keeps the refresh token | Yes, encrypted |
Both use ENTRA_CLIENT_ID / ENTRA_CLIENT_SECRET, and both present Power BI a
token issued to this server's own registration. Neither accepts a token that
Entra issued for a different resource, which the MCP authorization spec
prohibits.
Which to choose. obo is simpler and stores nothing long-lived; prefer it
where it works. Its limitation is structural: the exchange happens server-side,
so a conditional access policy that applies to the Power BI API but not to the
app the user signed in to fails with AADSTS50158, and the challenge arrives
somewhere the user cannot answer it.
custody exists for that case. The Power BI token comes from an authorization
code redeemed with the user's browser in the loop, so conditional access is
satisfied at sign-in. The cost is that the server holds a refresh token per
user: encrypted at rest, but durable access to Power BI as that user, so treat
the host accordingly.
The MCP client runs an OAuth flow against this server, which runs its own against Entra. Two relationships, and no token crosses a boundary it was not issued for.
client ──/authorize──▶ server ──▶ Entra ──▶ server /callback
client ◀── our code ── server (Entra's tokens stop here)
client ──/token─────▶ server ── our access + refresh token ──▶ clientConfigure PUBLIC_URL, CUSTODY_REDIRECT_URIS and SESSION_ENCRYPTION_KEY
(see .env.example), and add PUBLIC_URL/callback as a redirect
URI on the app registration.
PKCE with S256 is required of clients, redirect URIs are matched exactly,
authorization codes are single use with a 60 second life, and access and refresh
tokens are rotated together so a replayed one is refused. Only digests of the
tokens are stored, so the store never holds a usable credential. Dynamic client
registration is not supported; clients are configured.
When a stored refresh token stops working — revoked, expired, or a policy re-evaluation demanding interaction — the session is dropped and the client receives a 401, prompting a fresh sign-in.
Sharing an app registration. ENTRA_CLIENT_ID may be the same registration
your MCP client already uses, which avoids requesting a new one. Note that Entra
sign-in logs then cannot distinguish the two, and rotating the secret affects
both. Pointing ENTRA_CLIENT_ID at a dedicated registration later is a config
change.
Both modes serve RFC 9728 protected
resource metadata at /.well-known/oauth-protected-resource, naming this server
as the authorization server under custody and the Entra tenant under obo, so
a client can discover where to authenticate instead of being configured with it.
Custody also serves RFC 8414 metadata
at /.well-known/oauth-authorization-server. Every 401 carries a
WWW-Authenticate header pointing at the resource metadata.
The client points at whoever issues the tokens, which differs by mode.
AUTH_MODE=obo — the client authenticates against Entra:
mcpServers:
mcp-server-for-powerbi:
type: streamable-http
url: http://localhost:3001/mcp
requiresOAuth: true
oauth:
authorization_url: https://login.microsoftonline.com/<tenant-id>/oauth2/v2.0/authorize
token_url: https://login.microsoftonline.com/<tenant-id>/oauth2/v2.0/token
client_id: <client-id>
client_secret: <client-secret>
scope: "api://<api-app-id>/mcp.access openid profile offline_access"
redirect_uri: http://localhost:3080/api/mcp/mcp-server-for-powerbi/oauth/callbackAUTH_MODE=custody — the client authenticates against this server, which
holds the Entra credentials, so no client secret is configured here:
mcpServers:
mcp-server-for-powerbi:
type: streamable-http
url: http://localhost:3001/mcp
requiresOAuth: true
oauth:
authorization_url: https://powerbi-mcp.example.com/authorize
token_url: https://powerbi-mcp.example.com/token
client_id: librechat
scope: "powerbi.read"
redirect_uri: http://localhost:3080/api/mcp/mcp-server-for-powerbi/oauth/callbackThe redirect_uri must appear in CUSTODY_REDIRECT_URIS, and
authorization_url must be reachable from the user's browser — set PUBLIC_URL
to the external address if the server sits behind an ingress.
{
"mcpServers": {
"mcp-for-powerbi": {
"name": "mcp-for-powerbi",
"type": "stdio",
"isActive": true,
"registryUrl": "",
"command": "uv",
"args": [
"run",
"--directory",
"<your_directory>/mcp-server-for-powerbi",
"mcp-for-powerbi"
]
}
}
}Note: MCP client must pass OAuth token via Authorization header.
## Docker Deployment to Azure
- Login to Azure CLI and ACR
```bash
az login
az acr login --name <acr-name>Build the Docker image
docker build -t <acr-name>.azurecr.io/mcp-server-for-powerbi .Run the image locally for testing
docker run -it --rm -p 8080:8080 \
-e TENANT_ID=<tenant-id> \
-e AUDIENCE=<api-app-id> \
-e AUTH_MODE=obo \
-e ENTRA_CLIENT_ID=<client-id> \
-e ENTRA_CLIENT_SECRET=<client-secret> \
<acr-name>.azurecr.io/mcp-server-for-powerbiPush the image to ACR
docker push <acr-name>.azurecr.io/mcp-server-for-powerbiThe server raises structured MCP tool errors with detailed suggestions:
Missing Authorization – OAuth token not provided in Authorization header.
TokenExpired – obtain a fresh token (user tokens are short‑lived).
Unauthorized (401) – token is invalid or lacks required permissions.
Forbidden (403) – user lacks permission to the workspace or dataset.
NotFound (404) – invalid workspace_id or dataset_id.
BadRequest (400) – invalid parameters or DAX syntax errors.
TooManyRequests (429) – rate limit exceeded (120 requests per minute).
Timeout – network / API slowness (default timeout 30s).
Each error includes:
Error code and message from the Power BI API
Context-aware suggestions to help resolve the issue
Parameter validation for workspace_id and dataset_id (UUID format)
DAX-specific error analysis with syntax and semantic suggestions
This project is built on FastMCP v2 and draws inspiration from the following repositories:
Inspired by an internal project
Their approaches to semantic model surfacing and Power BI integration helped shape the tool design here.
This project is licensed under the MIT License. See the LICENSE file for details.
This project is an independent, open‑source MCP server for Microsoft Power BI. It is not affiliated with, endorsed by, or sponsored by Microsoft. “Power BI” is a trademark of Microsoft Corporation.
Execute a DAX query against a dataset.
This tool executes DAX (Data Analysis Expressions) queries against Power BI datasets. DAX queries must use the EVALUATE keyword for table expressions.
Args: workspace_id: The unique identifier of the Power BI workspace (UUID format). dataset_id: The unique identifier of the dataset (UUID format). dax_query: The DAX query text to execute. Must start with EVALUATE for table queries.
Returns: Query results with tables and rows, or error information if the query fails.
Common errors:
400 Bad Request: DAX syntax errors, invalid table/column references
403 Forbidden: Missing permissions or tenant setting not enabled
Limitations: Max 100,000 rows or 1,000,000 values per query
Example DAX query: EVALUATE TOPN(10, 'Sales')
Raises: ToolError: If parameters are invalid or query execution fails
| Name | Required | Description | Default |
|---|---|---|---|
| dax_query | Yes | ||
| dataset_id | Yes | ||
| workspace_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses common errors, limitations (max rows/values), and that query must start with EVALUATE. Does not explicitly state idempotency or read-only nature, but provides substantial behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections (Args, Returns, Errors, Example). Slightly verbose but front-loaded with purpose. Each section adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of DAX query execution and lack of annotations, the description is complete: covers parameters, errors, limitations, and example. Output schema exists but description adequately describes return types.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description thoroughly explains each parameter: workspace_id/dataset_id as UUIDs, dax_query must start with EVALUATE. Includes example, adding significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool executes DAX queries against Power BI datasets, using specific verbs and resource. It distinguishes itself from siblings which are about listing workspaces/datasets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for executing DAX queries but does not explicitly state when not to use it or provide alternatives. However, siblings are clearly distinct, so confusion is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve dataset (semantic model) metadata and structure.
Args: workspace_id: The unique identifier of the Power BI workspace (UUID format). dataset_id: The unique identifier of the dataset (UUID format).
Raises: ToolError: If workspace_id or dataset_id is missing or invalid format
| Name | Required | Description | Default |
|---|---|---|---|
| dataset_id | Yes | ||
| workspace_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions raising ToolError for invalid input, but does not disclose read-only nature, permissions, or other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Reasonably concise with a docstring-style format. Each sentence adds value, though the Args/Raises section slightly expands length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers parameters and error conditions, but does not explain return values (output schema exists) or provide details on what 'metadata and structure' includes. Adequate for a simple retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has no descriptions (0% coverage), but the description adds meaningful context by specifying UUID format and purpose for both parameters, compensating for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves dataset metadata and structure, with a specific verb and resource. It is distinct from siblings like list_datasets_in_workspace, but does not explicitly differentiate itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like list_datasets_in_workspace or execute_dax_query. Does not mention prerequisites or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the workspace ID for a given workspace name.
This tool is useful for finding the workspace ID when you only know the workspace name. The ID is required for other operations like listing datasets.
Args: workspace_name: The display name of the Power BI workspace.
Returns: The workspace ID as a string.
Raises: ToolError: If the workspace is not found.
| Name | Required | Description | Default |
|---|---|---|---|
| workspace_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description discloses that the tool raises a ToolError if not found. It's a simple get operation with no destructive side effects; description sufficiently covers behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with a brief summary and structured Args/Returns/Raises sections. No wasted sentences, front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 1-param tool with output schema, description covers purpose, parameter semantics, return value, and error case. No missing information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has no description for parameter workspace_name (0% coverage). Description provides meaning: 'The display name of the Power BI workspace.' Fully compensates for schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it gets the workspace ID for a given workspace name. Distinguishes from sibling tools like powerbi_list_workspaces which likely list all workspaces, whereas this is a lookup by name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use: when only the workspace name is known, and explains that the ID is needed for other operations. Does not explicitly mention when not to use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List datasets in the specified workspace.
Args: workspace_id: The unique identifier of the Power BI workspace (UUID format).
Raises: ToolError: If workspace_id is missing or invalid format
| Name | Required | Description | Default |
|---|---|---|---|
| workspace_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must cover behavioral traits. It only states 'List datasets' and describes the input, but omits any output behavior (e.g., pagination, whether the list includes all datasets, or any side effects). Even though an output schema exists, the description does not reference it or any operational characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose. It includes a structured Args and Raises section, using minimal sentences without any filler. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema (covering return structure), the description adequately explains the input and error handling. However, it could mention that it lists all datasets in the workspace or any limitations, though the output schema compensates somewhat. Still, it is mostly complete for a simple list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description adds meaningful information for workspace_id: 'The unique identifier of the Power BI workspace (UUID format)'. This clarifies the required format beyond the schema's plain type: string, making it easier for the agent to correctly invoke the tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'List datasets' and the context 'in the specified workspace', using a specific verb and resource. It distinguishes from siblings like get_dataset_details (single dataset) and execute_dax_query (querying), making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., get_dataset_details). It only mentions the required parameter and error, but no context for selection, such as 'use this to get a high-level overview' or contrasting with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all Power BI workspaces the user has access to.
Returns a list of workspaces with their IDs and names. This is useful for identifying which workspaces you can access and work with.
Common errors:
401 Unauthorized: Token is missing or invalid
403 Forbidden: Token expired or lacks required permissions
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes the return format (IDs and names) and common errors, implying a read-only listing. Without annotations, it carries the burden well, though no side-effect disclosure is needed for a list operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short paragraphs with clear front-loading: purpose and return first, errors second. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple list tool with an output schema. Covers workspace identification and errors, but could mention pagination or rate limits for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. The description adds value by specifying the scope ('the user has access to') and return structure (workspaces with IDs and names).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'List all Power BI workspaces the user has access to' with a specific verb and resource, and differentiates from sibling tools like get_workspace_id and list_datasets_in_workspace.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context that it is useful for identifying accessible workspaces, but lacks explicit guidance on when not to use or alternatives. Includes common error codes for troubleshooting.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.2.0execute_dax_queryget_dataset_detailsget_workspace_idlist_datasets_in_workspacepowerbi_list_workspacesScored across 5 tools
Each tool has a clearly distinct purpose: listing workspaces, getting workspace ID, listing datasets, getting dataset details, and executing DAX queries. There is no overlap or ambiguity.
Most tools follow a verb_noun pattern, but 'powerbi_list_workspaces' uses a 'powerbi_' prefix not present in others, creating a minor inconsistency. Otherwise, naming is clear and predictable.
With 5 tools, the server is well-scoped for core Power BI data access and metadata exploration. Each tool contributes to a coherent workflow without being excessive.
The tool set covers essential read and query operations but lacks management capabilities such as refresh, create, update, or delete. This limits completeness for full dataset lifecycle management.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Governed BI MCP. Ask questions of live company data and list workspace sources via OAuth.
List datasets, schemas, run APL queries, and use prompts for exploration, anomalies, and monitoring.
Run SOQL queries against your Salesforce org to explore and retrieve data. Quickly iterate on filt…
Run SOQL queries to explore and retrieve Salesforce data. Inspect records, fields, and relationshi…
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Mitsubishi-Fuso/mcp-server-for-powerbi'
If you have feedback or need assistance with the MCP directory API, please join our Discord server