The PowerBI Analyst MCP server connects AI agents (like Claude) to Power BI semantic models, enabling natural language analytics, DAX query execution, and schema exploration — all running locally on your machine.
Authentication & Sessions
Sign in via OAuth 2.0 device code flow with OS-native secure token storage, and log out/clear credentials when needed.
Discovery & Schema Exploration
List workspaces, apps, datasets, tables, measures (with descriptions/format strings), and columns (with data types/key flags).
Retrieve dataset metadata including owner, refresh schedule, and recent refresh history.
DAX Query Execution
Run any DAX query against a dataset; results ≤50 rows are returned inline as JSON, while larger results are auto-saved to a local CSV to avoid context window overload.
Page through large CSV files on demand using read_query_result.
Query History
A persistent local JSONL audit log tracks all DAX executions, user requests, and results across sessions.
Search history by keyword, dataset, or time range to reuse prior DAX patterns or locate saved result files.
Delete individual log entries for incorrect or misleading results.
Advanced Analytics
Compound reasoning: Chain multiple queries (explore schema → write DAX → page results → synthesize) to answer complex questions autonomously.
Natural language analytics: Translate plain-English questions into DAX queries and real answers without requiring technical knowledge.
Anomaly detection: Run scheduled queries to compare data against prior periods and flag unexpected patterns.
Data documentation: Auto-generate data dictionaries by exploring schemas and explaining measures.
Privacy & Distribution
All data, queries, and tokens stay on your machine — no third-party cloud relay.
Supports Claude Desktop, Cursor, and other MCP clients, with bundle deployment for team-wide distribution.
Ask Claude to analyse your Power BI data. Get answers — not context-window crashes.
Connect Claude (or any MCP client) to your Power BI semantic models. Explore tables and measures, run DAX queries, and work with real results — even across datasets with tens of thousands of rows. Large query results are automatically saved to a local file and paged to the agent on demand, so your AI session stays fast and focused no matter how much data you pull.
Everything runs on your machine. Your data never passes through a third-party relay.
The analytics bottleneck has never really been data access — Power BI already gives people access. The bottleneck is translation: the skilled, time-consuming work of turning data into a decision. This server moves that translation to an LLM.
Compound reasoning across your entire model A human analyst runs one query, reads the result, forms a hypothesis, runs another query. This serialises over hours. An agent can run twenty queries in sequence — each informed by the last — synthesise across all of them, and deliver a reasoned conclusion in minutes. Ask "what's driving the margin decline in EMEA?" and Claude will explore measures, drill into markets, check time trends, isolate the outlier, and explain it — without you directing each step.
Natural language analytics for everyone Any stakeholder can ask a data question and get a real answer backed by live DAX — without knowing what DAX is, without filing a ticket, without waiting. The translation layer that used to require a trained analyst runs on demand.
Proactive anomaly detection Run Claude on a schedule against your key measures. It queries the data, compares to prior periods, and flags anything outside expected ranges in plain English — before anyone has to open a dashboard to find out something went wrong.
Self-documenting semantic models "List every measure in this dataset and explain what it calculates." Claude explores the schema and produces a data dictionary — useful for onboarding, governance, and anyone trying to understand what a model actually contains.
Large datasets, handled automatically Power BI queries can return tens of thousands of rows. Returning all of that inline would consume most of an LLM's context window and crash the session. This server saves large results to a local CSV and gives the agent a compact summary — row count, column names, 5-row preview — then lets it page through the file on demand. You get the full dataset. The AI session stays lean.
Query history that compounds over time Every successful DAX query is logged locally in a JSONL audit trail — what the user asked, the DAX that was generated, the columns returned, and where the CSV was saved. In the next session, the agent searches this history to find relevant prior work: reusable DAX patterns, previously computed result files, and context from earlier analyses. The more you use it, the faster and smarter it gets — and you always have an audit trail of where every number came from.
Your data stays on your machine Queries, results, and tokens never pass through a cloud relay. The server runs locally, authenticates via the same OAuth device code flow as the Power BI web app, and stores tokens in your OS's native secure store (Keychain / DPAPI / LibSecret).
Related MCP server: mcp-snowflake-server
Microsoft publishes two MCP servers for Power BI. This one is different in purpose and architecture from both.
This server | |||
Purpose | Query and analyse existing models | Query existing models | Build and modify models |
Runs | Locally on your machine | Microsoft's cloud infrastructure | Locally (Power BI Desktop) |
Data path | Direct to Power BI REST API | Via Microsoft's MCP relay | Local XMLA |
Auth | OAuth device code (delegated) | OAuth via remote service | Local session |
Large results | Auto-saved to local CSV | In-context only | N/A |
Read-only | Yes | Yes | No |
Who it's for | Analysts using Claude / Cursor | Analysts using Copilot | Model developers |
You: Analyse revenue by market and product category for Q1 2025
Claude: Let me explore the dataset first.
[calls list_tables → list_measures → execute_dax]
The query returned 73,840 rows — saved to:
~/powerbi_output/dax_result_revenue_q1_2025_20260313_091204.csv
[pages through results with read_query_result]
Summary: EMEA leads at 44% of total revenue. The top category
is Premium Hardware in both EMEA and AMER. APAC shows the
strongest quarter-over-quarter growth at +18%...The agent explores the schema, writes the DAX, handles the file, and delivers the analysis — without you touching the Power BI UI.
Tool | What it does |
| Sign in via OAuth device code — returns a URL + one-time code; call again to complete |
| Clear the cached token (forces re-authentication) |
| List all Power BI apps you have access to — start here; returns |
| List datasets / semantic models in a workspace (use |
| Metadata and last 5 refresh history entries for a dataset |
| All visible tables in a dataset |
| Measures with name, table, description, and format string |
| Columns with data type and key flag |
| Run a DAX query — inline for small results, local CSV for large ones. Pass |
| Page through a large CSV result without loading it all into context |
| Search the local query log by keyword, dataset, or time range — find prior DAX and results across sessions |
| Remove a query log entry (e.g. when the approach turned out to be wrong) |
Python 3.10+
A Power BI Pro, Premium Per User (PPU), or Premium capacity licence
An Azure AD app registration (free, ~5 minutes — see below)
OAuth 2.0 requires a client ID to identify which application is acting on your behalf. The registration is free, requires no client secret, and does not need Power BI admin consent for the two read-only scopes used here.
Go to portal.azure.com → Azure Active Directory → App registrations → New registration.
Name it (e.g. PowerBI MCP). For account types choose Accounts in this organizational directory only (single-tenant). Click Register.
Under Authentication → Platform configurations, add Mobile and desktop applications and tick this redirect URI:
https://login.microsoftonline.com/common/oauth2/nativeclientStill under Authentication → Advanced settings, set Allow public client flows to Yes. Save.
Under API permissions → Add a permission → Power BI Service, add:
Dataset.Read.All
Workspace.Read.All
If your tenant requires admin consent, ask an admin to grant it.
From the Overview page, copy both of these — you will need them in Step 2:
Application (client) ID
Directory (tenant) ID
Note: The Power BI tenant setting "Dataset Execute Queries REST API" must be enabled in the Power BI Admin Portal (Integration settings) for
execute_daxto work.
The server is published on PyPI. The fastest way to run it is with uvx, which requires no manual install or virtual environment.
Add the following to your claude_desktop_config.json:
{
"mcpServers": {
"powerbi": {
"command": "uvx",
"args": ["powerbi-analyst-mcp"],
"env": {
"POWERBI_CLIENT_ID": "your-application-client-id",
"POWERBI_TENANT_ID": "your-directory-tenant-id"
}
}
}
}The config file is at:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
POWERBI_TENANT_IDis required for almost all users. Most organisations have a single Azure AD tenant. Set this to your Directory (tenant) ID from Step 1. Leaving it asorganizations(the default) will cause authentication to fail or target the wrong tenant.
Add a .cursor/mcp.json file in your project (or use the global config):
{
"mcpServers": {
"powerbi": {
"command": "uvx",
"args": ["powerbi-analyst-mcp"],
"env": {
"POWERBI_CLIENT_ID": "your-application-client-id",
"POWERBI_TENANT_ID": "your-directory-tenant-id"
}
}
}
}pip install powerbi-analyst-mcpThen replace the uvx command block with:
"command": "powerbi-analyst-mcp",
"args": []A .mcpb (MCP Bundle) is a ZIP archive that Claude Desktop installs via drag-and-drop — no manual config editing required. The bundle auto-installs all Python dependencies on first run; the only prerequisite is Python 3.10+.
Two manifests live in bundle/:
File | Purpose | Git |
| Generic — prompts the user for credentials at install time via Claude's UI | Committed |
| Org-specific — credentials hardcoded for silent deployment | Gitignored — never commit |
Building an org bundle:
# 1. Create your org manifest (one-time setup)
cp bundle/manifest.template.json bundle/manifest.jsonEdit bundle/manifest.json and set your values in mcp_config.env:
"env": {
"POWERBI_CLIENT_ID": "your-application-client-id",
"POWERBI_TENANT_ID": "your-directory-tenant-id",
"POWERBI_OUTPUT_DIR": "/custom/output/path"
}POWERBI_OUTPUT_DIR is optional — omit it entirely to use the default ~/powerbi_output.
# 2. Build the bundle
chmod +x bundle/build.sh
./bundle/build.sh
# → dist/miinto-powerbi-analyst.mcpb (gitignored)Distributing: Share dist/*.mcpb with colleagues. They drag-and-drop it onto Claude Desktop → Settings → Developer. Works on macOS and Windows.
Security:
bundle/manifest.jsonanddist/are both gitignored. Only the credential-free template is committed. Never add credentials to any file tracked by git.
Once connected, ask your LLM to follow this sequence naturally:
1. authenticate ← first run only; returns a URL + code to open in browser,
then call authenticate again to complete sign-in
2. list_apps → returns installed apps, each with a workspaceId
3. list_datasets workspace_id=<workspaceId from app> → returns dataset IDs
4. list_tables workspace_id=<id> dataset_id=<id>
5. list_measures workspace_id=<id> dataset_id=<id> [table_name=<name>]
6. list_columns workspace_id=<id> dataset_id=<id> [table_name=<name>]
7. search_query_history [keyword="revenue"] ← check if similar work exists from a prior session
8. execute_dax workspace_id=<id> dataset_id=<id>
dax_query="EVALUATE SUMMARIZECOLUMNS(...)"
[query_summary="Revenue by market and product for Q1 2025"]
[result_name="revenue by market q1"] ← names the saved CSV
[max_rows=500] ← optional row cap for sampling
9. read_query_result file_path=<savedTo> [offset=0] [limit=100]
← page through large results without filling contextNote: Always use
list_apps(notlist_workspaces) to discover workspace IDs. In app-managed organisations, dataset access is granted through Power BI apps — using workspace IDs fromlist_workspacesmay result in permission errors.
-- Total sales by year
EVALUATE
SUMMARIZECOLUMNS(
'Date'[Year],
"Total Sales", [Total Sales]
)
ORDER BY 'Date'[Year]
-- Top 10 customers by revenue
EVALUATE
TOPN(
10,
SUMMARIZECOLUMNS('Customer'[Name], "Revenue", [Revenue]),
[Revenue], DESC
)
-- Filtered subset
EVALUATE
CALCULATETABLE(
'Sales',
'Date'[Year] = 2024
)Result size | What happens |
≤ 50 rows | Returned inline as JSON — zero friction |
> 50 rows | Full result saved to a timestamped CSV; agent receives a compact summary |
The summary returned for large results contains:
rowCount — total rows written
columns — column names and types
preview — first 5 rows
savedTo — absolute path to the CSV file
The agent can then page through the file with read_query_result:
read_query_result(
file_path = "/path/from/savedTo",
offset = 0, # zero-based row offset
limit = 100 # rows per page (default 100)
)Returns rows, totalRows, offset, limit, and hasMore. Increment offset by limit to fetch the next page.
execute_dax parameters for controlling result size:
Parameter | Type | Description |
|
| Short description of what the user asked for — logged to the local query history for auditability and cross-session reuse. |
|
| Short label used in the CSV filename — e.g. |
|
| Hard cap applied via |
Output directory defaults to ~/powerbi_output. Override with POWERBI_OUTPUT_DIR in your MCP client's env block. CSV files and the query history log are not automatically cleaned up — manage the directory manually or add a retention policy.
Read-only. Creation, modification, and deletion of Power BI artefacts are not supported.
execute_dax limits: 100,000 rows or 1,000,000 values per query (Power BI API hard cap).
Rate limit: 120 DAX query requests per minute per user.
list_tables, list_measures, and list_columns use the DAX INFO.VIEW.* functions, which require Import or DirectQuery models with XMLA read access enabled.
CSV files written by execute_dax are not automatically cleaned up.
Tokens are persisted using OS-native secure storage via msal-extensions:
macOS — Keychain
Windows — DPAPI-encrypted file
Linux — LibSecret (gnome-keyring / KWallet); falls back to an encrypted file if unavailable
The cache file is written to ~/.powerbi_mcp_token_cache.bin and is covered by .gitignore.
The server never logs access tokens.
All data access is gated by the user's own Power BI permissions (delegated OAuth 2.0 — no service principal, no client secret).
See CONTRIBUTING.md for project structure, dev environment setup, architecture notes, and how to add new tools.
Authenticate with Power BI using the OAuth 2.0 device code flow.
Call this tool first if you have never logged in, or if a previous call returned "Not authenticated".
The tool uses a two-step flow:
First call: returns a URL and a one-time code for you to open in a browser.
Second call: completes the authentication after you have signed in.
Your credentials are cached locally so you will not need to repeat this step until the refresh token expires (~90 days).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Remove a single entry from the query history log.
Use this when a query produced incorrect or misleading results and should not appear in future history searches. The associated CSV file (if any) is NOT deleted — only the log entry is removed.
| Name | Required | Description | Default |
|---|---|---|---|
| entry_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Execute a DAX query against a Power BI dataset and return the result rows.
The query must start with EVALUATE (standard DAX query syntax). Results are returned as a JSON array of objects, with column names as keys.
Small results (<= 50 rows) are returned inline as JSON.
Large results (> 50 rows) are automatically saved to a CSV file and a
compact summary is returned with the file path, column names, row count,
and a preview of the first 5 rows. Use read_query_result to page
through a saved CSV, or read the file directly.
Every successful execution is logged to a local history file for
auditability and cross-session reuse. Use search_query_history to
find prior queries. The query_summary parameter makes history search
much more effective — always provide it when you can.
Limitations imposed by the Power BI API:
Maximum 1,000,000 values or 100,000 rows per query.
Rate limit: 120 requests per minute per user.
Only DAX is supported; MDX and DMV queries are not.
The tenant setting "Dataset Execute Queries REST API" must be enabled.
Tips:
Use TOPN or FILTER to limit large result sets.
Use SUMMARIZECOLUMNS for aggregated queries.
Use CALCULATETABLE for filtered table expressions.
Use max_rows to sample a large table without rewriting the DAX.
Use result_name to give the saved CSV a meaningful filename.
| Name | Required | Description | Default |
|---|---|---|---|
| workspace_id | Yes | ||
| dataset_id | Yes | ||
| dax_query | Yes | ||
| max_rows | No | ||
| result_name | No | ||
| query_summary | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Return detailed metadata for a single Power BI dataset.
Includes name, owner, refresh schedule, storage mode, web URL, and more. Also returns the last 5 refresh history entries so you can see data freshness.
| Name | Required | Description | Default |
|---|---|---|---|
| workspace_id | Yes | ||
| dataset_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
List all Power BI apps installed for the authenticated user.
Returns each app's id, name, description, publisher, last update time,
and — most importantly — the workspaceId of the underlying workspace.
Use the workspaceId field (not the app id) as the workspace_id
parameter in list_datasets, list_tables, execute_dax, and other
dataset tools.
If no apps are installed, try list_workspaces instead to find
workspaces directly.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
List columns (dimensions) in a Power BI dataset.
Returns each column's name, parent table, description, data type, and whether it is a key column. Optionally filter by table name.
| Name | Required | Description | Default |
|---|---|---|---|
| workspace_id | Yes | ||
| dataset_id | Yes | ||
| table_name | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
List all datasets (semantic models) in a Power BI workspace.
Returns dataset id, name, configured-by, web URL, is-refreshable flag,
and the target storage mode (Import / DirectQuery / etc.).
Use the id field as dataset_id in subsequent tools.
| Name | Required | Description | Default |
|---|---|---|---|
| workspace_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
List measures defined in a Power BI dataset.
Returns each measure's name, parent table, description, and format string. Optionally filter by table name.
| Name | Required | Description | Default |
|---|---|---|---|
| workspace_id | Yes | ||
| dataset_id | Yes | ||
| table_name | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
List all visible tables in a Power BI dataset.
Hidden tables and internal Power BI system tables (names starting with '$')
are excluded. Use the returned table names in list_measures,
list_columns, and DAX queries.
| Name | Required | Description | Default |
|---|---|---|---|
| workspace_id | Yes | ||
| dataset_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
List all Power BI workspaces (groups) the authenticated user is a member of.
Returns workspace id, name, type, and capacity information.
Use the id field as workspace_id in subsequent tools.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Sign out of Power BI by clearing the cached credentials.
After logging out, call authenticate to sign in again.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Read a page of rows from a CSV file saved by execute_dax.
Use this tool when execute_dax returns a savedTo path instead of
inline rows. Combine offset and limit to page through large results
without loading the entire file into context.
Returns rows for the requested slice together with pagination metadata:
totalRows: total number of rows in the file
offset: the offset used
limit: the limit used
hasMore: whether more rows exist after this page
Example workflow:
Call execute_dax — if rows > 50 you get a savedTo path.
Call read_query_result(file_path=savedTo, offset=0, limit=100).
If hasMore is true, call again with offset=100, then 200, etc.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | ||
| offset | No | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Search the local query history log for prior DAX executions.
Every successful execute_dax call is logged with the DAX query,
a short summary of what the user asked for, the result shape, and
the path to any saved CSV file. Use this tool to:
Find previous queries for a dataset so you can reuse or adapt the DAX
Locate saved CSV files from earlier sessions
Audit what data has been pulled and when
Avoid re-running expensive queries when the data already exists locally
Results are returned newest-first. Use keyword to search by intent
(e.g. "revenue by market") — it matches against the query summary,
the DAX text, and the result name.
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | No | ||
| dataset_id | No | ||
| since_days | No | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.2authenticatedelete_query_log_entryexecute_daxget_dataset_infolist_appslist_columnslist_datasetslist_measureslist_tableslist_workspaceslogoutread_query_resultsearch_query_historyScored across 13 tools
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.
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.
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.
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.
GA4, Google Ads and Search Console in Claude. Read-only OAuth, multi-account for agencies.
Query your warehouse or a CSV with Claude/ChatGPT over MCP, governed by table-level ACL + audit.
Connect Claude to your Platform7n workspaces — chat, links, and tasks. One-click OAuth.
Connect Claude, Cursor, or ChatGPT to your business data. Ask questions, get answers.
