PowerBI MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.2
Disambiguation5/5
Each tool has a clearly distinct purpose: singular vs list retrieval for datasets, separate tools for parameters, refresh history, reports, workspaces, and querying. No overlaps.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern, e.g., get_dataset, get_datasets, get_parameters. query_dataset uses 'query' instead of 'get' but still matches the pattern, maintaining overall consistency.
Tool Count5/5
With 7 tools covering dataset, report, workspace, parameter, refresh history, and query operations, the count is well-scoped for a focused PowerBI data retrieval server.
Completeness3/5
The server covers read operations comprehensively (list, get, query) but lacks any write capabilities (e.g., create, update, delete, refresh). This is a notable gap for full lifecycle management, though it may be sufficient for a read-only analysis tool.
Average 4.5/5 across 7 of 7 tools scored. Lowest: 3.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on February 5, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It explains the retrieval behavior and parameters but does not explicitly state that the tool is read-only or non-destructive, which is important for an agent to understand side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear opening, bullet points, and sections for parameters, returns, examples, and errors. It is slightly verbose with background on Power BI datasets but overall efficiently organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three optional parameters and an output schema (not shown but present), the description covers usage, return structure (list with IDs, names, optional metadata), and error handling. It provides sufficient context for an agent to understand and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates by explaining each parameter's purpose, defaults, and valid values (e.g., format: 'json' or 'markdown'). It clarifies the use of workspace_id for My workspace omission, adding value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get list of datasets from a specific workspace or My workspace,' clearly identifying the resource and scope. It includes usage bullet points that hint at differentiation from siblings like get_dataset (single) and query_dataset (querying), but does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use cases (e.g., 'Find a dataset ID for querying') and error handling tips. However, it does not state when not to use this tool or directly compare with sibling tools, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Explains return values, error cases (workspace ID not found, permission errors, empty list), and implies read-only behavior. Transparent about behavior beyond basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections for parameters, returns, examples, and error handling. Some redundancy (e.g., 'Returns report information including' and later list), but mostly concise and front-loaded with main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and low schema coverage, description compensates well. Explains return fields, error handling, and usage. Output schema exists but not shown; description covers return values. Could include more details on auth requirements or rate limits.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No input schema descriptions (0% coverage), but description fully explains each parameter: workspace_id optional (default My workspace), format options (json/markdown), detail levels (concise/detailed). Provides usage examples that clarify semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it gets PowerBI reports from a workspace, listing specific return information (report name, ID, URLs, dataset ID). Distinguishes from siblings like get_dataset (which gets a single dataset) and get_workspaces (which lists workspaces).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides useful context: 'Useful for discovering available reports and getting report URLs.' Includes example usage and error handling scenarios. However, does not explicitly state when not to use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It notes read-like behavior (retrieves metadata) and provides error handling (404, permissions). It does not mention idempotency or side effects, but the tool is clearly a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, usage, parameters, returns, examples, errors). It front-loads the key action and uses bullet points for easy scanning, with no wasted sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 params, read operation) and presence of an output schema, the description covers all necessary aspects: purpose, parameters, expected returns, examples, and error guidance. It is complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds meaning for all three parameters: dataset_id (unique identifier), workspace_id (optional, omit for My workspace), and format (json or markdown defaults). This compensates well for missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get detailed information about a specific dataset' and distinguishes from siblings like get_datasets (which lists datasets) and get_refresh_history. It uses a specific verb-resource pair and contrasts with other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists bullet-pointed use cases (e.g., 'Check dataset configuration') and includes error handling advice referencing get_datasets as an alternative. However, it does not explicitly state when not to use this tool or directly compare with siblings like get_parameters or get_reports.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses return content, unsupported connections, and error scenarios (not found, unsupported, empty result). It does not mention idempotency or side effects, but for a read operation, transparency is good.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (returns, notes, parameters, examples, error handling). It is somewhat lengthy but front-loaded with the main purpose. Every sentence adds value, though it could be slightly more concise without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters (1 required) and output schema existence, the description is thorough: covers purpose, parameters, return fields, usage notes, unsupported scenarios, and error handling. No major gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description fully compensates. It explains each parameter: dataset_id (required), workspace_id (optional, My workspace), format (default markdown), detail (default concise). Examples clarify usage, adding meaning beyond schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool's purpose: 'Get parameters defined in a PowerBI dataset.' It is specific with a clear verb and resource, and it distinguishes itself from sibling tools (none of which retrieve parameters).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates when to use the tool ('Useful for discovering available parameters before querying parameterized datasets') and notes unsupported dataset types. It also provides error handling guidance. However, it does not explicitly contrast with sibling tools, but no direct alternative exists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description fully covers behavior: lists returned fields, includes default values/max for top, mentions error cases, and implies read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections, but slightly verbose; front-loaded with purpose, though some redundancy exists (e.g., repeating 'Get refresh history').
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, so return field details aren't needed; description gives sufficient overview of returns and covers usage comprehensively. Minor gap: no mention of pagination or rate limits.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description explains all 4 parameters in detail (required/optional, defaults, format options) and adds usage context beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb+resource ('Get refresh history for a PowerBI dataset') and distinguishes from siblings like get_dataset or query_dataset by focusing on refresh operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
States use cases (monitoring data freshness, troubleshooting failures) and provides examples and error handling, but does not explicitly contrast with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description fully discloses behavior: it retrieves workspaces, supports pagination (top/skip), offers format and detail options, and includes error handling for authentication and permissions. No hidden traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections (overview, usage, parameters, returns, examples, errors) but is slightly verbose. Every sentence adds value, so it earns a high score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, no annotations, and an output schema, the description covers usage, parameters, examples, and error handling comprehensively. An agent can confidently invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description compensates fully. It explains each parameter (top for max count, skip for pagination offset, format for response type, detail for level of detail) and provides examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves a list of PowerBI workspaces accessible to the service principal. It uses specific verbs ('Get list of') and distinguishes from sibling tools that focus on datasets, reports, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists use cases (discover workspaces, find workspace ID, list all accessible) and provides error handling scenarios. It lacks explicit when-not-to-use but the context of sibling tools makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It mentions the 100-row limit in markdown, error handling, and return format. However, it does not explicitly confirm that queries are read-only, though examples suggest so.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (description, usage, syntax, parameters, returns, examples, error handling). It is front-loaded with the main purpose and every sentence adds value without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of DAX queries, the description covers all necessary aspects: purpose, parameters, return format, row limits, error handling, and references to get_dataset. It is comprehensive for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description provides clear meanings for all parameters, including workspace_id (omit for My workspace), format options, and DAX query syntax requirements. Examples further clarify usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Execute DAX queries against a PowerBI dataset' with a specific verb and resource. It distinguishes itself from siblings like get_dataset by focusing on querying data rather than metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists when to use the tool (retrieve data, perform calculations, filter, etc.) and provides error handling advice, including referring to get_dataset for schema. This serves as an implicit alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![powerbi-mcp MCP server](https://glama.ai/mcp/servers/gurvinder-dhillon/powerbi-mcp/badges/card.svg)](https://glama.ai/mcp/servers/gurvinder-dhillon/powerbi-mcp)

Score Badge

Copy to your README.md:

[![powerbi-mcp MCP server](https://glama.ai/mcp/servers/gurvinder-dhillon/powerbi-mcp/badges/score.svg)](https://glama.ai/mcp/servers/gurvinder-dhillon/powerbi-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/gurvinder-dhillon/powerbi-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server