Which Microsoft Fabric MCP Server Do You Need?

TL;DR

Microsoft ships ten official Model Context Protocol (MCP) servers for Fabric: six remote, four local, each answering a different kind of task. Picking the wrong one is the most common reason an AI agent stalls out mid-workflow. The fix is a decision tree keyed to what you're actually trying to do, not to the acronym: manage the tenant, build or author something, or ask an existing thing a question.

• The split. Six servers are remote endpoints you authenticate to (Fabric Core, Data Agent, Fabric IQ Ontology, Fabric Data Warehouse, the Real-Time Intelligence remote endpoints, Power BI). Four run as local subprocesses you install (Fabric MCP local, Fabric RTI local, DataFactory, Power BI local).
• The catch. Eight of the ten are in preview. Tool names and response shapes on those can change release to release, so re-check before shipping anything that depends on one.
• The payoff. Once one server is connected, an agent answers from your real tenant instead of a training-data guess. Add a second server only when the task needs it.

Why you need this

You ask an AI coding assistant something reasonable: "What lakehouses exist in my Sales workspace, and does CustomerOrders have a schema I can build a model against?"

Without anything connecting the assistant to your tenant, you get a guess dressed up in confident language. The model has never seen your workspace. It knows what a lakehouse generally is, not what is actually in yours.

Model Context Protocol (MCP) closes that gap. Strip the acronym away and it is a simple idea: a standard way for an AI agent to discover and call tools, instead of every AI product hand-wiring a bespoke integration to every system it touches.

• An MCP server exposes a system's capabilities as named, typed tools: "list workspaces," "execute a DAX query," "upload a file to OneLake." It doesn't care which AI calls it.
• An MCP client (built into VS Code with GitHub Copilot, or Claude Code) connects to one or more servers, discovers their tools, and hands them to the model.
• The agent reads your request, picks the right tool, calls it, and turns the structured result into a natural-language answer.

Write a server once, and every MCP-compatible AI tool can use it. For a Fabric developer, that buys live answers instead of training-data guesses, one interface across a genuinely fragmented surface (OneLake, Data Factory, Real-Time Intelligence, Power BI, each historically its own SDK), and permissions that travel with the person: the official servers enforce your existing Entra ID identity and Fabric RBAC, not a blanket service credential. This guide takes you from not knowing what that means to a working, governed connection, using only servers Microsoft has actually published.

The ten servers

Every row here is something Microsoft built and documents on Learn.

Three things worth knowing before you touch any of them. Preview isn't a formality: tool names and response shapes on these can change release to release. The remote Power BI server needs a tenant admin to flip a setting on first, with its query-generation tool consuming a Copilot license. And the Data Warehouse server exposes exactly one tool, executeSQL: there's no separate schema-browsing tool, so the agent discovers tables by querying INFORMATION_SCHEMA through that same tool.

Most confusion isn't how to install a server, it's which one answers the task in front of you. Here's the same ten servers, routed by what you're trying to do:

The rule of thumb underneath it: local servers are for building (you're changing a model, a file, a pipeline), remote servers are for asking (you're querying something that already exists without running infrastructure). A real workflow often registers one of each.

Your first connection

Every official server follows one of two setup patterns.

Local server (stdio). The local Fabric MCP Server, RTI local, DataFactory, and local Power BI server all work this way. In VS Code, install the Fabric MCP Server extension and it registers itself. In Claude Code:

claude mcp add fabric-local -- npx -y @microsoft/fabric-mcp@latest server start --mode all

Remote server (OAuth). Fabric Core, Fabric Data Warehouse, the RTI remote endpoints, the remote Power BI server, the Data Agent server, and the Ontology server all work this way. No install, just a URL and a sign-in. In VS Code: command palette, then MCP: Add Server, then HTTP, then paste the endpoint. In Claude Code:

claude mcp add --transport http fabric-core https://api.fabric.microsoft.com/v1/mcp/core

This registers in a "needs authentication" state. Run /mcp, select the server, choose Authenticate, and complete the Entra ID sign-in that opens in your browser.

Either pattern ends the same way: ask something grounded ("What Fabric workload types are available?"), and if the answer comes from the tool instead of a guess, you're connected.

Using more than one

One server answers one kind of question. A real workflow runs several together, and because an agent is now acting on a live tenant, it needs guardrails.

• Register more than one, deliberately, at project scope. A typical set is small: Fabric Core for context, the local server you're actively building on, and one domain server if the task needs it. Registering at project scope (.mcp.json for Claude Code, .vscode/mcp.json for VS Code) ships the registration with the project instead of your personal config.
• Add the Microsoft Learn MCP Server for everything else. It's a free, no-auth, remote server that searches and fetches Microsoft's own documentation, not just Fabric, everything Microsoft publishes on Learn. It isn't a Fabric server, but it's the natural pairing: your agent checks a claim against current docs instead of guessing from training data.
• Write repeatable procedures down, don't re-explain them. Once you're calling the same tool sequence for the same kind of task, turn it into a reusable instruction file or Claude Code skill that names which tools to call and in what order.
• Put a check before anything irreversible. No official server has a universal "confirm before destructive action" flag. Build that yourself, especially around anything still preview.
• Know where the compliance boundary sits. Microsoft states explicitly that once a response leaves an official server and lands in your AI client, it's subject to that client's own data-handling terms. Fine for development. Worth a second look before regulated data goes through the same path in production.

Three pitfalls catch people early. A local server dies with your session (it's a subprocess, no daemon, so check whether the client restarted if a tool disappears). Remote doesn't mean available (the remote Power BI server needs a tenant admin toggle most developers can't flip themselves). And row-level security has a gap under service principals: the remote Power BI server enforces RLS for signed-in users but explicitly not for service-principal authentication. Verify, don't assume.

The bottom line

MCP doesn't add intelligence to Fabric development. It removes the translation layer between what you want to ask and the API call that answers it. Governance, RBAC, and what's actually GA are unchanged. MCP just lets an agent reach it in your words instead of the API's.

Pick the row in the decision tree that matches today's task, connect one server, and watch it answer from your real tenant instead of a guess. Add a second server when the task needs it. That's the whole climb, and nothing on it requires anything Microsoft hasn't already shipped.

One thing this piece doesn't settle: everything above assumes an agent acting as you. Under a service principal, or once a broader agent control plane sits in front of Fabric, does row-level and object-level security enforcement survive that hop? Real open question, bigger than a footnote here. Next piece.