Loading ToolBench
MCP Server for Power BI providing workspace, dataset, and DAX query tools with OAuth support
The server provides 8 tools with consistent naming (all start with action verbs: get_, execute_, refresh_), clear descriptions averaging ~80 characters, and complete input schemas with typed parameters. However, output schemas are not documented, parameter descriptions lack detail about formats/constraints, and error handling guidance is minimal. Tool names are verb-noun patterns that follow conventions well, but descriptions could be more LLM-optimized with specifics about when to use each tool vs alternatives. No tool annotations (readOnlyHint/destructiveHint) despite having mixed READ_ONLY and WRITE operations.
Execute a DAX query against a Power BI dataset and return results
Get detailed information about a Power BI dataset including tables, columns, and measures
Get the refresh schedule for a Power BI dataset
List all datasets in a specified Power BI workspace
Get the refresh history for a Power BI dataset
Get capacity information for a Power BI workspace
List all Power BI workspaces the user has access to
Output schemas are not documented. Tool descriptions state what is returned (e.g., 'List all Power BI workspaces') but do not specify the structure, fields, types, or pagination behavior. LLMs cannot plan downstream calls without knowing what data structure to expect.
Parameter descriptions lack constraint details. 'workspace_id' and 'dataset_id' are documented as strings, but descriptions do not explain the format (UUID? Numeric? Pattern?), length, or where to obtain them if unknown. This forces LLMs to guess or make extra discovery calls.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 67 | <=2025-11-25 | v2 |
Trigger a refresh of a Power BI dataset
No tool annotations despite mixed risk levels. 7 tools are READ_ONLY, 1 is WRITE (refresh_dataset). The fastmcp framework supports readOnlyHint and destructiveHint annotations, but they are not used. This leaves LLMs unable to distinguish safe vs unsafe operations from the tool definition alone.
execute_dax_query lacks error recovery guidance. The code (lines ~263-280 in server.py) mentions MAX_RESULT_BYTES and truncation warnings, but the tool description does not explain how truncation is signaled, what to do if results exceed limits, or how to break large queries into smaller chunks. LLMs will not know how to handle a partial result.
No pagination guidance. get_workspaces and get_datasets descriptions do not mention pagination parameters (limit, offset, cursor) or total counts, yet production Power BI workspaces can have many datasets. Without pagination, results could exceed context windows or truncate silently.
Tool descriptions are below recommended 50-200 character range for LLM optimization. Most descriptions (65-75 chars) are at the lower bound. They lack context about when to call the tool, what data is returned, or why it differs from similar tools.