Model Connection
manage_model_connection is the tool the assistant uses to discover available models/datasets and connect the MCP server to the one you choose.
Everything else in the MCP server depends on this context. If the assistant is connected to the wrong model, results will be wrong.
You typically won’t call tools directly. Tell the LLM what you want (connect/list/confirm), and it will use this tool behind the scenes.
What to ask the LLM (quick prompts)
“List available models/datasets and ask me which one to connect to (don’t auto-select).” “Connect to the Power BI Desktop model for this open PBIX.” “Connect to the Power BI Service dataset ‘Sales Model’ in workspace ‘Finance’.” “Show what we’re currently connected to and confirm it matches what I expect.” “Reload metadata; I changed the model outside this session.” “Sign out of Power BI Service in this session, then confirm we’re disconnected from Service auth.”What you can do (from a user perspective)
- Discover available models (Desktop instances or Service datasets).
- List Service workspaces first so dataset identifiers are stable for repeat sessions.
- Connect/switch the active model/dataset.
- Verify the current connection (source, model name, IDs).
- Refresh/reload metadata after external changes.
- Authenticate to Service when needed, and sign out when required by your org process.
- (Where supported) set an impersonation context for RLS testing.
Desktop vs Service (how to choose)
Desktop (local PBIX)
Use Desktop when you’re working with:
- a local PBIX opened in Power BI Desktop,
- local model authoring workflows.
What to expect:
- You’ll see one or more Desktop instances/models.
- The assistant should ask you which one to connect to if there are multiple.
If you only have one model open, some deployments may auto-select it. If you want strict “always ask me”, tell your admin to disable auto-select for this environment.
Service (Power BI Service via XMLA)
Use Service when you need:
- to work against a dataset in Power BI Service,
- workspace-scoped context for certain workflows (governance defaults, shared baselines),
- Service-only behaviors (where available).
Common prerequisites:
- an XMLA-capable workspace/capacity for the dataset,
- authentication to Service (if not already authenticated).
If Service datasets don’t appear, ask:
“Is Power BI Service (XMLA) connectivity enabled in this environment? If not, what’s missing?”Selecting the right model (best practice)
Before doing any non-trivial work, ask the assistant to confirm the model context in plain English:
“Confirm the current model/dataset (and workspace if Service). Then proceed.”If there are multiple candidates with similar names:
“Show me the list and include stable identifiers so I can pick the right one.”Stable identifiers (Service) and why “list workspaces” matters
For Power BI Service (XMLA), the server can generate:
- stable IDs when it knows the workspace GUID (resilient to workspace renames), and
- unstable IDs when it only has workspace names (names can change).
Best practice:
“List workspaces first, then list datasets in workspace ‘Finance’, then ask me which one to connect to.”If you skip the workspace listing step, the assistant may still connect successfully, but you lose stability for repeatable instructions (“connect to X again tomorrow”).
Browse-only privacy behavior (what gets hidden)
In browse-only deployments, discovery outputs are leak-minimized. For example, Desktop model listing may omit local file paths and connection URIs.
If you need to pick the right Desktop model in browse-only mode:
- close extra PBIX files (keep only one open), or
- ask for timestamps (“last modified”) and model names, then select explicitly.
Impersonation context (RLS testing)
This tool can set a session-level impersonation context used by subsequent queries (for example, “run all queries as role SalesTeam”).
Prompts:
“Set session impersonation to roleSalesTeam and confirm it’s active.”
“Clear impersonation context and confirm queries run with admin permissions.”
Tip: query plan/timings capture is incompatible with impersonation. If you want deep performance traces, clear impersonation and rerun the query without role/user context.
Locked-down environments (mode behavior)
Even in browse-only mode, this tool is usually available because you must be able to select a model to browse.
| Mode | Availability |
|---|---|
| Full mode | AvailableAvailable |
| Read-only mode | AvailableAvailable |
| Browse-only mode | AvailableAvailable |
Notes: Service requires XMLA enabled/auth; Desktop requires an open PBIX.
Common workflows
1) Connect (Desktop)
Prompt:
“List Power BI Desktop models and ask me which one to connect to.”If you have multiple PBIX files open:
“List all Desktop models with their file names/ports; I’ll pick one.”Note: file path/port details may be suppressed in browse-only mode.
2) Connect (Service)
Prompt:
“List Service workspaces and datasets I can access. Ask me which dataset to connect to.”Then:
“Connect to dataset ‘X’ in workspace ‘Y’. Confirm it’s connected.”If authentication is required:
“Authenticate to Power BI Service, then retry listing workspaces/datasets.”3) Confirm current context (always do this before big work)
Prompt:
“Show current connection context (Desktop vs Service, model name/id), and confirm it matches ‘X’.”4) Reload metadata after external edits
Prompt:
“Reload model metadata. I changed measures/relationships outside this session.”5) Prepare RLS testing context (when applicable)
Prompt:
“Set up RLS testing for role ‘SalesTeam’. Then run a small validation query and summarize the difference vs no role.”Troubleshooting
Ask:
“Show me the list and wait for my selection. Do not auto-select.”Ask:
“Is Service connectivity enabled? Is this dataset XMLA-capable? Do I need to authenticate?”Ask:
“Walk me through authenticating to Service in this client, then retry listing datasets.”Ask:
“Confirm what model is actually connected and why (e.g., Desktop instance changed).”