How your data reaches Claude
The full path data takes — from your source database, through Microsoft Fabric mirroring, to Claude generating visualizations — and the role the MCP server plays in the middle.
Currently being tested in a personal project on one desktop before rolling out as the shared version shown above.
The six layers, in order
Each box in the diagram above corresponds to one of these.
Source database
The live, operational SQL database that runs the business day to day. This is the system of record; nothing downstream ever writes back to it.
Fabric Mirroring
A managed Microsoft service that continuously copies data into OneLake as Delta tables, without adding load to the source database.
SQL analytics endpoint
An auto-generated, read-only, standard T-SQL interface on top of the mirrored data — this is what Data API Builder actually connects to.
SQL MCP Server
The translation layer between Claude and the database — covered in detail below. This is the piece that makes the whole thing possible.
Claude Desktop
The chat app itself. It holds the connector to the MCP server and calls its tools whenever a conversation needs live data.
Shared Claude Project
A persistent workspace with custom instructions and the connector pre-loaded for every team member. Each person gets a private copy of the same setup — nobody edits a config file; they just open the project and get guided from there.
What is the MCP server actually doing?
MCP (Model Context Protocol) is an open standard that lets Claude connect to external tools and data sources. An "MCP server" is a small program that exposes a fixed, predefined set of actions — called tools — that Claude is allowed to call.
Here the MCP server is Data API Builder (DAB), running locally via dab start. It connects to the Fabric SQL analytics endpoint on one side and exposes a small set of database tools to Claude on the other. It does not let Claude run arbitrary SQL — a deliberate safety design. Claude can only call these tools, each scoped to the tables you explicitly added:
Because every table was added with "anonymous:read" permissions, none of these tools can create, modify, or delete anything — the connection is read-only end to end.
No local install, no config files — access depends only on an Entra ID sign-in, from any device.
The six layers, in order
Each box in the diagram above corresponds to one of these.
Source database
The live, operational SQL database that runs the business day to day. This is the system of record; nothing downstream ever writes back to it.
Fabric Mirroring
A managed Microsoft service that continuously copies data into OneLake as Delta tables, without adding load to the source database.
SQL analytics endpoint
An auto-generated, read-only, standard T-SQL interface on top of the mirrored data — this is what Data API Builder actually connects to.
Hosted SQL MCP Server
The same translation layer, but running as a persistent service (e.g. Azure Container Apps) instead of on one laptop — reachable over the public internet, behind Microsoft Entra ID so only authorized sign-ins get through.
Shared Claude Project
Same instructions and connector concept, but pointed at the hosted MCP server instead of localhost. An Owner adds it once in Organization Settings; nobody configures anything on their own machine.
Team members
Anyone reaches the same data from claude.ai in a browser, the mobile app, or Claude Desktop — Anthropic's cloud connects to the hosted endpoint on their behalf, after they sign in with their own Entra ID account.
What changes vs. the desktop setup?
The MCP layer itself is identical — same Data API Builder, same fixed set of tools, same read-only permission model. What changes is where it runs and how it's reached: instead of dab start in a terminal on one laptop, it runs as an always-on hosted service with a public HTTPS address, with Microsoft Entra ID in front so a request only gets through after a valid sign-in.
Hosting it centrally trades a bit of setup work — someone stands up and maintains the service and owns the auth configuration — for zero setup work per person. Worth weighing that trade-off deliberately; it's a real ongoing responsibility, not a one-time task.
