powerbi-orchestrator-mcp

Overview Schema Source Related Servers Discussions Admin

deploy_to_workspace

Deploy a .pbip project to a Fabric/Power BI workspace, run pre-deploy quality gates, and schedule daily dataset refreshes upon publication.

Instructions

Deploy a PBIP project to a Fabric/Power BI workspace with pre-deploy gates.

Use this tool when the user asks to:

Deploy, publish, or release a Power BI project (.pbip) to Microsoft Fabric or Power BI Service.
Run pre-deployment quality gates before publishing.
Schedule automatic daily dataset refreshes upon publication.

Args: pbip_path: Local filesystem path to the root .pbip directory. workspace_id: Target Fabric / Power BI workspace ID (UUID). refresh_daily_hour: Daily UTC hour (0-23) for scheduled refresh (default: 6 AM UTC). findings_json: Optional list or JSON string of pre-existing audit findings to evaluate. gate_profile: Quality gate profile ("strict", "standard", "lenient"). auth_mode: "interactive" (default, browser login) or "service_principal". tenant_id: Azure AD tenant ID. client_id: Azure AD client ID. client_secret: Azure AD client secret. mock: If True, simulate deployment without calling external APIs.

Returns: Dict with deployment status, gate evaluation results, published item IDs, and refresh configuration.

Input Schema

TableJSON Schema

Name	Required	Default
`mock`	No
`auth_mode`	No	interactive
`client_id`	No
`pbip_path`	Yes
`tenant_id`	No
`gate_profile`	No	standard
`workspace_id`	Yes
`client_secret`	No
`findings_json`	No	[]
`refresh_daily_hour`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv1.11.0Oct 2, 2026
- removedInput schema / properties / findings_json / type
```
Removed value: -"string"
```
First observedv0.1.0Sep 10, 2026

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden and does well: it discloses pre-deploy gate evaluation, published item IDs, scheduled daily refreshes, auth modes, and a mock/dry-run flag. It stops short of stating required permissions, reversibility, or side effects on an existing workspace deployment.

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?

Front-loaded purpose followed by scannable when-to-use bullets, then Args and Returns. Given 10 undocumented parameters, the length is justified and nothing repeats structured data.

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?

For a 10-parameter deployment tool with no annotations and 0% schema coverage, the description supplies the missing parameter meaning, auth guidance, dry-run option, and return shape (with an output schema also present). Nothing an agent needs to invoke it correctly is absent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate and largely does — all 10 params are documented with types, defaults (6 AM UTC, 'standard', 'interactive'), and allowed values ('strict'/'standard'/'lenient', interactive/service_principal). It could go further by explaining what the gate profiles actually mean or the findings_json shape.

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?

States a specific verb + resource + scope ('Deploy a PBIP project to a Fabric/Power BI workspace with pre-deploy gates'), which lets an agent distinguish it from siblings like pre_deploy_check and promote_in_pipeline without opening a schema.

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?

Gives an explicit when-to-use list covering deploy/publish, running quality gates, and scheduling refreshes. It does not, however, name the adjacent siblings (pre_deploy_check, promote_in_pipeline) or state exclusions, so an agent must infer boundaries between overlapping tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.