msfabric-mcp

A Model Context Protocol server for Microsoft Fabric, over stdio, in Python.

It gives an agent one connection that reaches both halves of Fabric:

• the control plane, through the public REST API at api.fabric.microsoft.com/v1 (workspaces, items, lakehouses, warehouses, notebooks, the job scheduler), and

• the data plane, through the SQL analytics endpoint of a warehouse or lakehouse, behind an allowlist read-only guard.

Plus optional DAX against a Power BI semantic model.

Read-only by default. Writes are refused unless the operator sets FABRIC_ALLOW_WRITES, and even then UPDATE and DELETE must carry a WHERE.

• Package: msfabric-mcp on PyPI

• Repository: https://github.com/NawafSheikh/fabric-mcp

• MCP registry name: io.github.nawafsheikh/msfabric-mcp

• License: MIT

Honest positioning

Fabric MCP is a crowded shelf as of 2026-08-22. Here is what already exists and where this one differs. Nothing below is a claim that the others are bad.

Where msfabric-mcp sits:

1. One server across both planes. Microsoft's Core MCP server is control plane only; you still need a second thing to run a query. Here, list_items and run_sql live in the same process and the same credential.

2. Local stdio, no preview enrollment. The Microsoft servers are remote and in preview. This runs on your machine against the generally available REST API, so it works in any tenant you can already sign in to.

3. The guard is the product. run_sql is an allowlist, not a blocklist: a statement runs only when it is positively classified as a read (or as a permitted write with writes enabled). Comments are stripped first, statement batches are refused, and procedure execution, OPENROWSET/OPENQUERY, GRANT/REVOKE, BACKUP/RESTORE and SHUTDOWN are refused in every mode.

4. Bounded output. Every result set is capped in rows and in cell width, and says when it truncated, so a wide SELECT * cannot flood a context window.

If you only need control-plane browsing inside a tenant that has the preview enabled, use Microsoft's Core MCP server; it is first-party and will always track the API faster. Use this one when you want SQL and jobs in the same server, locally, with a hard read-only default.

Related MCP server: Databricks MCP Server

Install

pip install msfabric-mcp

SQL access needs a driver. Pick one:

pip install "msfabric-mcp[sql]"     # pyodbc, plus ODBC Driver 18 for SQL Server
pip install "msfabric-mcp[mssql]"   # mssql-python, no external ODBC manager

• pyodbc needs ODBC Driver 18 for SQL Server installed separately (17 also works). The Entra token is passed with the SQL_COPT_SS_ACCESS_TOKEN connection attribute (1256).

• mssql-python is Microsoft's own driver, needs Python 3.10+, installs its connectivity layer with the wheel, and supports Fabric Data Warehouse and the Lakehouse SQL analytics endpoint.

The REST tools need neither driver. You can run the server with no SQL configuration at all and still browse workspaces, items and jobs.

Requires Python 3.11 or later.

Configure

Everything comes from environment variables. Nothing about a tenant, workspace, warehouse or host is compiled into the package. See .env.example.

Authentication

Three modes, all built on azure-identity.

1. DefaultAzureCredential (the default). Set nothing. The credential chain picks up an az login session, a VS Code sign-in, a managed identity, or the standard AZURE_CLIENT_ID / AZURE_TENANT_ID / AZURE_CLIENT_SECRET environment service principal.

az login

2. Service principal. Set all three and the mode is inferred:

The service principal must be added to the workspace with Admin, Member or Contributor, and the tenant setting Service principals can call Fabric public APIs must be on.

3. Device code, for a headless box or an SSH session:

FABRIC_AUTH_MODE=device_code
FABRIC_CLIENT_ID=<a public client app registration>

Tokens are cached in memory per scope and refreshed two minutes before expiry. They are never written to disk, never logged, and never appear in any error message the server returns.

Scope and SQL

Safety

No secret is ever printed. health reports whether a tenant id, client id and secret are configured, never their values, and error messages carry an exception class and a short service detail with the query string stripped.

Client configuration

Claude Desktop, Claude Code, or any stdio MCP client:

{
  "mcpServers": {
    "fabric": {
      "command": "msfabric-mcp",
      "env": {
        "FABRIC_WORKSPACE_ID": "00000000-0000-0000-0000-000000000000",
        "FABRIC_SQL_ENDPOINT": "your-endpoint.datawarehouse.fabric.microsoft.com",
        "FABRIC_SQL_DATABASE": "your_warehouse"
      }
    }
  }
}

Do not put FABRIC_CLIENT_SECRET in a config file that lives in a repository. Use az login, a managed identity, or a secret manager that injects the variable into the server process.

Tools

Notebook and lakehouse arguments accept either a display name or an id; a name is resolved through list_items on the fly.

The SQL guard, precisely

run_sql accepts one statement per call, with comments stripped before any decision is made. Then:

• Starts with SELECT or WITH, and contains no SELECT ... INTO or FOR UPDATE: classified read, always allowed.

• Starts with INSERT, UPDATE, DELETE, MERGE, CREATE, ALTER, DROP, TRUNCATE, or is a SELECT ... INTO: classified write. Refused unless FABRIC_ALLOW_WRITES is set. UPDATE and DELETE additionally require a WHERE clause even when writes are enabled.

• Anything else: refused, because it matched neither shape.

• EXEC/EXECUTE, sp_*, xp_*, OPENROWSET, OPENDATASOURCE, OPENQUERY, BULK INSERT, GRANT, REVOKE, DENY, BACKUP, RESTORE, SHUTDOWN, RECONFIGURE: refused in every mode.

• Multiple statements separated by ;: refused, so each one can be judged alone.

Table and schema names supplied to describe_table are validated as plain identifiers and the lookup itself is parameterised, so a name cannot carry SQL.

This is a guard against an agent's mistakes, not a substitute for permissions. Grant the identity the least access it needs; the workspace role and the warehouse's own object permissions remain the real boundary.

Notes on execute_dax

Uses the JSON executeQueries endpoint rather than the newer Arrow executeDaxQueries, because executeQueries works on Pro, PPU and Premium/Fabric capacities and needs no Arrow library. Its documented ceiling is 100,000 rows and 1,000,000 values per query; FABRIC_MAX_ROWS applies on top of that. The tenant setting Dataset Execute Queries REST API must be enabled, and the caller needs Build permission on the semantic model. Only EVALUATE and DEFINE queries are accepted.

What it touches

• Outbound HTTPS to api.fabric.microsoft.com, api.powerbi.com, and Microsoft Entra for tokens.

• Outbound TDS on 1433 to your SQL analytics endpoint, only when a SQL tool is called and FABRIC_SQL_ENDPOINT is set. Encrypt=yes, TrustServerCertificate=no.

• No local filesystem writes. No telemetry. No third-party service.

Develop

git clone https://github.com/NawafSheikh/fabric-mcp
cd fabric-mcp
pip install -e ".[dev]"
pytest
python -m build

The whole test suite runs with no network, no Fabric tenant, and no ODBC driver installed: REST calls go through an httpx.MockTransport, and the SQL layer takes an injectable connection factory that the tests fill with a fake DB-API connection.

Contributing

Issues and pull requests welcome at https://github.com/NawafSheikh/fabric-mcp/issues.

Sources

Checked 2026-08-22.

• Fabric REST API: Items

• Fabric REST API: Workspaces

• Fabric REST API: Job Scheduler

• Manage and execute notebooks in Fabric with APIs

• Manage a lakehouse with the REST API (List Tables)

• OneLake catalog and Fabric REST APIs

• mssql-python support lifecycle (Fabric endpoints)

• Microsoft Python Driver for SQL Server

• Azure Identity client library for Python

• Power BI: Execute Queries

• Power BI: Execute DAX Queries (Arrow) overview

• Fabric Core MCP Server tools reference

• Remote Power BI MCP server