How to Connect Claude to Microsoft Fabric Through MCP

What the connection is for

Microsoft Fabric brings lakehouses, warehouses, pipelines, notebooks, and reports into one platform organised by workspace. An MCP server for Fabric exposes that platform to an agent: list workspaces and items, inspect table schemas, run queries, and in some configurations create or modify items.

The value is speed on the tedious parts of data work. An analyst can ask which tables in a lakehouse hold customer order data, have the agent inspect the schemas, draft a query, run it against a small sample, and explain the result. Work that meant clicking through several panes becomes a conversation.

Setup, in order

Microsoft publishes a hosted Fabric Core MCP server, in public preview at the time of writing, that exposes the Fabric REST APIs as MCP tools and authenticates through browser-based OAuth with Microsoft Entra ID. Microsoft documents it as working with MCP clients including Claude Desktop. That is the shortest route: point the client at the hosted endpoint and sign in, rather than running a server yourself. Self-hosted and community servers remain an option where you need tools the hosted one does not expose, or where policy keeps the connection inside your own network.

Preview status matters for planning: endpoints, tool names, and configuration can change, so pin the current documentation rather than a blog post, and expect to revisit the setup.

Product screens and server options change, so follow this sequence and check the current server documentation for exact commands.

What to let it do first

• Explore. List items, describe tables, find where a field lives. This is safe and immediately useful.
• Draft queries. Have the agent write SQL against a warehouse or lakehouse endpoint, run it with a row limit, and explain what it returned.
• Document. Ask for a summary of a workspace's items and how they connect. Agents are good at producing the documentation nobody wrote.

Hold back on writes. Creating items, modifying pipelines, or triggering runs can consume capacity and change production data flows. Add those abilities individually, with a human approving each action until you have a track record.

The gap the schema does not fill

The agent can see that a table has a column named status with values 1 through 5. It cannot see that 4 means refunded but only after March, when the codes changed, or that finance excludes internal test accounts from every revenue figure.

That knowledge lives in data dictionaries, wiki pages, old tickets, and people's heads. Without it the agent writes queries that run correctly and answer a slightly different question than the one asked, and returns a confident number anyway.

Write the definitions and caveats down, index them, and connect that index alongside the Fabric server. The agent then retrieves the relevant definition before drafting a query instead of inferring meaning from column names.

Guardrails worth having

• Row limits by default. Instruct the agent to sample before running full queries, so exploration does not scan large tables or eat into capacity.
• Logging. Keep the MCP server's logs and review what the agent ran in the first weeks.
• Separate environments. Point the agent at development or test workspaces before production ones.
• Sensitive data. If workspaces hold personal or regulated data, check whether results flowing to a hosted model are acceptable under your policies before connecting them at all.

None of these slow down the useful work much. They make the difference between an experiment that gets approved for wider use and one that gets shut down after its first surprise.