PowerBI Analyst MCP

by mbrummerstedt

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.2
Disambiguation5/5
Every tool has a distinct, well-defined purpose with no overlap. For example, list_datasets enumerates datasets, get_dataset_info provides metadata for a specific dataset, execute_dax runs queries, and read_query_result handles pagination of saved results. The tools are clearly differentiated by their specific functions within the Power BI domain.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern using snake_case. Examples include authenticate, delete_query_log_entry, execute_dax, get_dataset_info, list_apps, list_columns, list_datasets, list_measures, list_tables, list_workspaces, logout, read_query_result, and search_query_history. This uniformity makes the tool set predictable and easy to navigate.
Tool Count5/5
With 13 tools, the count is well-scoped for a Power BI analytics server. It covers authentication, dataset exploration, query execution, result handling, and history management without being overwhelming. Each tool serves a clear purpose, such as listing resources, executing DAX, or managing logs, making the set comprehensive yet manageable.
Completeness4/5
The tool set provides strong coverage for core Power BI workflows, including authentication, dataset listing and inspection, DAX query execution, and result pagination. Minor gaps exist, such as the lack of tools for creating or modifying datasets, reports, or dashboards, but these are not essential for the stated analyst focus. The tools support a complete query and exploration lifecycle without dead ends.
Average 4.2/5 across 13 of 13 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on April 13, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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.
This repository includes a glama.json configuration file.
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.
View related servers

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?
With no annotations provided, the description carries the full burden. It successfully discloses return values (name, parent table, description, format string) and filtering behavior, but fails to state whether the operation is read-only/safe or describe pagination/error behaviors.
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 optimally structured with three efficient sentences: purpose first, return values second, parameter behavior third. Every sentence earns its place with zero redundancy or waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description appropriately focuses on purpose and high-level behavior rather than return structure details. However, with zero schema descriptions and no annotations, the omission of required parameter semantics (workspace_id, dataset_id) leaves notable gaps for a three-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, requiring the description to compensate. It explains the optional table_name parameter ('Optionally filter by table name'), but provides no semantic context for the two required parameters (workspace_id, dataset_id), leaving critical identifiers undocumented.
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 provides a specific verb (List) and resource (measures) with clear scope (Power BI dataset). It effectively distinguishes from siblings like list_columns or list_tables by specifying the exact metadata resource being retrieved.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lacks explicit guidance on when to select this tool versus alternatives like list_columns or get_dataset_info. While it mentions optional filtering by table_name, this describes parameter behavior rather than tool selection criteria or prerequisites.
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 provided, the description carries the full burden of behavioral disclosure. It successfully documents return content specifics (name, owner, refresh schedule, storage mode) and crucially discloses the 'last 5 refresh history entries' limit, which explains data freshness capabilities. It lacks mention of auth requirements or rate limits, but covers the primary behavioral contract.
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?
Three sentences with zero waste: first states purpose, second details metadata fields, third specifies refresh history behavior. Information is front-loaded and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description appropriately summarizes return values without redundancy. However, for a tool with required parameters and 0% schema coverage, the complete omission of workspace_id and dataset_id explanations leaves a significant documentation gap that the description should have addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% (titles only). The description mentions 'single Power BI dataset' which conceptually maps to dataset_id, but completely omits workspace_id despite it being a required parameter. With zero schema coverage, the description fails to compensate by explaining either parameter's purpose or format.
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 the tool 'Return[s] detailed metadata for a single Power BI dataset' — specific verb (return), specific resource (metadata), and scope (single dataset). It effectively distinguishes from sibling 'list_datasets' by emphasizing 'single' versus list operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
While the description implies this tool is for detailed retrieval versus the sibling 'list_datasets', it provides no explicit guidance on when to use this over alternatives, prerequisites (e.g., obtaining IDs from list_workspaces/list_datasets first), or when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It successfully discloses filtering behavior (excludes hidden tables and system tables prefixed with '$'), but omits safety properties (read-only status), rate limits, or pagination behavior that would be expected for a data retrieval tool.
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?
Three well-structured sentences with zero waste: purpose declaration, behavioral constraints (filtering), and usage guidelines (chaining). Information is front-loaded and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, the description appropriately does not detail return values. However, with 0% schema coverage on inputs and only two required parameters, the description should have documented the workspace/dataset parameters. Adequate but missing critical input documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% (no descriptions for workspace_id or dataset_id), and the description fails to compensate by explaining these parameters. While it mentions operating 'in a Power BI dataset' providing loose context, it does not explicitly map to or define the required parameters.
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 provides a specific verb ('List') and resource ('visible tables in a Power BI dataset'), clearly defining the scope. It distinguishes itself from potential siblings by specifying it excludes hidden/internal tables and explicitly mentions it feeds into `list_measures` and `list_columns`.
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 explicit chaining guidance: 'Use the returned table names in `list_measures`, `list_columns`, and DAX queries', directly referencing sibling tools. Also implies scope limitations (excludes hidden tables), though it could more explicitly state when NOT to use it.
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 provided, the description carries full burden and successfully discloses return structure (5 specific fields returned) and filtering behavior. It appropriately describes the output content since structured output schema exists. Minor gap: no mention of error behavior (e.g., empty dataset) or permission requirements, but core behavior is transparent.
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?
Three sentences with zero waste: sentence 1 states purpose, sentence 2 documents return values, sentence 3 covers optional filtering. Front-loaded with the primary action, no redundant or marketing language. Efficient information density.
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 the simple 3-parameter schema (2 required, 1 optional, no nesting) and existence of output schema, the description provides appropriate coverage. It explains the tool's scope, return summary, and key optional functionality. Could improve by explicitly noting required parameters given 0% schema coverage, but sufficient for agent selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, requiring the description to compensate. It successfully explains the optional table_name parameter ('Optionally filter by table name'), but does not explicitly document workspace_id or dataset_id. However, these are somewhat implied by 'Power BI dataset' context and standard hierarchical API patterns, making this minimally adequate rather than deficient.
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?
Description clearly states 'List columns (dimensions) in a Power BI dataset' - specific verb, resource, and domain. The parenthetical '(dimensions)' effectively distinguishes this from sibling tool list_measures (which handles calculated measures) and list_tables (containers), clarifying this returns column-level metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies usage through return value enumeration (name, data type, key status) and mentions 'Optionally filter by table name,' suggesting when to use the table_name parameter. However, it lacks explicit guidance on when to choose this over list_tables (schema exploration flow) or prerequisites like needing workspace_id/dataset_id from prior calls.
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 provided, the description carries the full burden and succeeds by detailing the specific output fields returned (id, name, configured-by, web URL, is-refreshable, storage mode). It also clarifies the 'semantic models' synonym, adding helpful domain context.
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?
Three tightly focused sentences: purpose declaration, output specification, and chaining instruction. Every sentence earns its place. Information is front-loaded with the core action in the first sentence.
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 the tool has an output schema (per context signals), the description adequately summarizes return values without needing full duplication. The inclusion of semantic model terminology and field-level output details provides good domain coverage. Only gap is the undocumented required parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (only title 'Workspace Id' provided). The description mentions 'in a Power BI workspace' which provides semantic context for the parameter, but fails to explicitly name `workspace_id` or explain how to obtain it (e.g., via `list_workspaces`). Insufficient compensation for the schema gap.
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 the action (List), resource (datasets/semantic models), and scope (Power BI workspace). It effectively distinguishes from sibling tools like `get_dataset_info` (list vs. get) and `list_workspaces` (datasets vs. workspaces) through specific terminology.
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 clear guidance on output chaining ('Use the `id` field as `dataset_id` in subsequent tools'), which helps the agent understand the tool's role in workflows. Lacks explicit contrast with `get_dataset_info` for when to use list vs. get, but implies bulk retrieval through 'List all'.
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 provided, the description carries the full burden of behavioral disclosure. It excellently clarifies data preservation ('The associated CSV file...is NOT deleted'), which is critical for a deletion tool. Minor gap: it doesn't state whether the deletion is irreversible or mention any permission requirements.
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?
Three sentences with zero waste: purpose (sentence 1), usage context (sentence 2), and critical behavioral caveat (sentence 3). Information is front-loaded and density is high.
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 the tool has an output schema (exempting return value documentation) and only one parameter, the description is nearly complete. It covers the primary behavioral quirk (CSV preservation). The only gap is the lack of parameter explanation necessitated by 0% schema coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% (entry_id lacks a description field), so the description must compensate. It fails to do so—never mentioning entry_id, its format, or how to obtain it (e.g., from search_query_history). 'Single entry' implies identification is needed but provides no 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?
The description opens with the specific verb 'Remove' and identifies the exact resource ('single entry from the query history log'). It clearly distinguishes this from sibling tool search_query_history (which retrieves entries) and execute_dax (which creates entries).
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?
Provides explicit when-to-use guidance ('Use this when a query produced incorrect or misleading results'). It also clarifies the scope limitation ('should not appear in future history searches'), helping the agent understand this affects searchability rather than data storage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses return values ('workspace id, name, type, and capacity information'), which is helpful. However, it omits other behavioral traits like rate limits, caching behavior, or explicit confirmation that this is read-only (though implied by 'List').
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?
Three sentences, each earning its place: purpose statement, return value disclosure, and usage guidance. Front-loaded with the core action. No redundant or wasteful text.
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 0 parameters and existence of output schema (per context signals), the description is complete. It covers the tool's function, output summary, and integration pattern with the tool ecosystem.
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?
Input schema has 0 parameters. Per scoring rules, 0 params = baseline 4. No parameter documentation needed.
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?
Description uses specific verb 'List' with clear resource 'Power BI workspaces (groups)' and scope 'authenticated user is a member of'. Clearly distinguishes from sibling tools like list_datasets or list_tables by specifying '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 explicit guidance on using output: 'Use the `id` field as `workspace_id` in subsequent tools.' This helps the agent understand the chaining pattern, though it doesn't explicitly state when NOT to use it or name specific alternative tools.
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 provided, the description carries the full burden of behavioral disclosure, specifying the destructive side effect of 'clearing the cached credentials' and the consequent requirement to re-authenticate, though it omits details on idempotency or error states when already logged out.
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 consists of two efficiently structured sentences with the core action front-loaded in the first sentence and workflow guidance in the second, containing no redundant or wasted text.
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 the tool's low complexity (zero parameters), the presence of an output schema (removing the need to describe return values), and the adequate coverage of the authentication state mutation, the description provides sufficient context for invocation.
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?
The input schema contains zero parameters, establishing a baseline score of 4; the description appropriately makes no reference to parameters since none exist, requiring no additional semantic clarification beyond the 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?
The description uses specific verbs 'Sign out' and 'clearing' with the resource 'Power BI' and 'cached credentials', clearly distinguishing it from sibling tools like `authenticate` which handles sign-in, while this handles sign-out.
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 workflow guidance by naming the sibling tool `authenticate` as the necessary next step ('call `authenticate` to sign in again'), effectively establishing the tool's place in the authentication lifecycle, though it does not explicitly state negative conditions (when not to use).
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 provided, the description carries the full burden and effectively discloses pagination mechanics, return structure (hasMore, totalRows), and file dependencies. Minor gap: no mention of error handling (e.g., missing files) or file lifecycle.
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?
Well-structured with core purpose front-loaded. The example workflow efficiently illustrates the interaction pattern, and the return value documentation adds necessary context despite the presence of an output schema.
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 the tool's moderate complexity and the existence of an output schema, the description is complete. It successfully explains the relationship with `execute_dax`, pagination strategy, and provides a concrete multi-step workflow example.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, requiring the description to compensate. It demonstrates parameter usage through the example workflow (offset=0, limit=100) and pagination context, but lacks explicit definitions for each parameter's semantics and constraints.
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 opens with a specific verb+resource ('Read a page of rows from a CSV file') and immediately ties it to the sibling tool `execute_dax`, clearly distinguishing its purpose from other list/read tools in the suite.
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?
Explicitly states the trigger condition ('Use this tool when `execute_dax` returns a `savedTo` path instead of inline rows'), providing clear when-to-use guidance and implicitly contrasting it with the inline result alternative.
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?
Without annotations, the description carries the full burden and succeeds in explaining what data is stored (DAX query, summary, result shape, CSV path), result ordering (newest-first), and keyword matching logic (matches summary, DAX text, result name). Minor gap: does not explicitly state this is read-only/safe, though implied by 'Search'.
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?
Efficient multi-paragraph structure: purpose upfront, data content second, bullet list for use cases, and usage mechanics (ordering/keyword) in the final sentence. Zero redundancy; every sentence adds value beyond the structured schema.
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 the output schema exists, the description appropriately omits return value details. It comprehensively covers use cases, search semantics, and result ordering. Minor gap: does not mention that all parameters are optional or explicitly contrast with delete_query_log_entry.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage. The description compensates well for 'keyword' (explaining intent-based searching and matching fields) and implies 'dataset_id' usage ('Find previous queries for a dataset'). However, 'since_days' and 'limit' are completely undocumented, leaving gaps for optional parameters that control result volume.
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 opening sentence 'Search the local query history log for prior DAX executions' provides a specific verb (Search), resource (local query history log), and scope (prior DAX executions). It clearly distinguishes from sibling tools like execute_dax (which creates entries) and delete_query_log_entry (which removes them).
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?
Excellent explicit guidance including four specific bullet-point scenarios (reuse queries, locate CSVs, audit data, avoid expensive re-runs). It explicitly references sibling tool execute_dax ('Every successful `execute_dax` call is logged'), clarifying the relationship between execution and history retrieval.
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?
With no annotations provided, the description carries full burden and excels: discloses the 50-row threshold for CSV spillover, API limits (1M values/100K rows, 120 req/min), tenant setting requirements, audit logging behavior, and result format specifics (JSON array vs CSV summary).
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 logical sections (purpose, result handling, history, limitations, tips). Front-loaded with the core purpose. Lengthy but justified by complexity and lack of annotations/schema docs; 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?
Comprehensive for a complex query tool with 0% schema coverage. Covers authentication prerequisites (tenant setting), pagination strategy, rate limiting, and result handling patterns. With output schema present, the dual-mode return explanation (inline JSON vs CSV) provides necessary context.
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?
Despite 0% schema description coverage, the description compensates effectively for 4 of 6 parameters: dax_query (EVALUATE requirement), max_rows (sampling purpose), result_name (CSV naming), and query_summary (history searchability). The workspace_id and dataset_id are implied but not explicitly described.
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 opening sentence provides a specific verb (Execute), resource (DAX query against Power BI dataset), and output (result rows). It clearly distinguishes this from metadata siblings like list_tables or list_datasets by focusing on arbitrary DAX query execution.
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?
Explicitly references sibling tools read_query_result (for paging large CSVs) and search_query_history (for finding prior queries). Also clarifies when not to use (MDX/DMV not supported) and provides DAX pattern tips. Could be improved by contrasting with get_dataset_info for metadata vs data retrieval.
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 provided, the description carries the full burden of behavioral disclosure. It successfully documents the return structure (id, name, description, publisher, last update time, workspaceId) and implies read-only access via the verb 'List.' However, it stops short of explicitly stating safety characteristics or error conditions.
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 efficiently structured with four sentences: purpose, return values, usage instructions for downstream tools, and fallback guidance. Every sentence provides critical information without redundancy, placing the most important information first.
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 that an output schema exists (per context signals), the description appropriately focuses on explaining the semantic importance of specific fields (particularly `workspaceId`) rather than exhaustively listing all return fields. It adequately covers the tool's role in the ecosystem with siblings like `list_workspaces` and `execute_dax`.
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?
The input schema contains zero parameters, establishing a baseline score of 4. The description appropriately does not mention parameters, which is correct given the empty schema requires no additional semantic explanation.
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 the specific action (List) and resource (Power BI apps) with scope (installed for the authenticated user). It effectively distinguishes this from sibling tool `list_workspaces` by clarifying that this returns apps and their underlying workspaceIds, not workspaces directly.
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?
Provides explicit guidance on when to use an alternative: 'If no apps are installed, try `list_workspaces` instead.' It also clearly specifies how to use the output with other tools, emphasizing to use `workspaceId` (not app `id`) for `list_datasets`, `execute_dax`, and other dataset tools.
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?
With no annotations provided, the description carries the full burden and delivers excellent behavioral context. It discloses the OAuth 2.0 device code flow mechanics, the two-step interaction pattern (browser URL + code), local credential caching behavior, and the ~90 day refresh token expiration timeline.
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 paragraph breaks separating purpose, usage conditions, flow mechanics, and caching details. Every sentence provides necessary information without redundancy, making it appropriately concise yet complete.
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 that this is an authentication tool with an output schema (implying structured return data), the description appropriately focuses on the conceptual flow and when to invoke rather than specific return field syntax. It adequately covers the authentication lifecycle and prerequisites for the sibling Power BI tools.
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?
The input schema contains zero parameters, which establishes a baseline score of 4. The description correctly requires no additional parameter clarification since there are no inputs to document.
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 'Authenticate[s] with Power BI using the OAuth 2.0 device code flow,' providing a specific verb, resource, and authentication method. It clearly distinguishes this from the sibling 'logout' tool by describing the login flow and credential caching.
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 provides explicit guidance: 'Call this tool first if you have never logged in, or if a previous call returned "Not authenticated".' It also details the two-step invocation pattern (first call for URL/code, second call to complete), which is essential for correct sequencing.
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-analyst-mcp MCP server](https://glama.ai/mcp/servers/mbrummerstedt/powerbi-analyst-mcp/badges/card.svg)](https://glama.ai/mcp/servers/mbrummerstedt/powerbi-analyst-mcp)

Score Badge

Copy to your README.md:

[![powerbi-analyst-mcp MCP server](https://glama.ai/mcp/servers/mbrummerstedt/powerbi-analyst-mcp/badges/score.svg)](https://glama.ai/mcp/servers/mbrummerstedt/powerbi-analyst-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/mbrummerstedt/powerbi-analyst-mcp'

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