Permissions required to use Data Warehouse MCP Server

Hi philipadc​,
Microsoft's documentation recommends verifying workspace roles, item permissions, and SQL permissions when troubleshooting permission errors. Please confirm that affected users have at least Read permission on the specific SQL analytics endpoint, along with the required SQL data-reading permissions. If these permissions are already configured correctly, test the item-scoped MCP endpoint and compare the results with the global endpoint.
Share Your Warehouse and Manage Permissions - Microsoft Fabric | Microsoft Learn
SQL granular permissions in Fabric Data Warehouse - Microsoft Fabric | Microsoft Learn
Connect to Fabric Data Warehouse MCP Server - Microsoft Fabric | Microsoft Learn

Thank you.

Hi philipadc​,

The pattern you describe (Excel works, the MCP server doesn't) suggests the failure isn't the SQL permission itself. Excel opens a TDS connection straight to the endpoint, and ReadData is enough for that. A server that takes a workspace ID + item ID usually has to resolve that item through the Fabric REST API first, to get the item metadata and connection details. Those workspace-scoped item APIs generally need a workspace role, and item-level sharing doesn't grant that.

I don't know the DW MCP server internals for certain, but you can confirm the theory quickly by calling the item lookup as one of the affected users:

# run as an affected user (item share only, no workspace role)
$token = (Get-AzAccessToken -ResourceUrl "https://api.fabric.microsoft.com").Token
$h = @{ Authorization = "Bearer $token" }

# item lookup by ID - expect 403/404 if this is the blocker
Invoke-RestMethod -Headers $h `
  -Uri "https://api.fabric.microsoft.com/v1/workspaces/<wsId>/sqlEndpoints/<endpointId>"

If that call fails while the same user can query the endpoint from SSMS or Excel, the blocker is the REST lookup, not the SQL grant.

Two things to try then. First, your note says you're on the generic all-databases endpoint. If the MCP server supports an item-specific endpoint configuration, test that for these users, since it may skip the workspace-level lookup. Second, if it really does need a workspace role, the clean workaround is a separate consumer workspace containing only what these users should see (shortcuts or a dedicated lakehouse). Give them Viewer there, so the workspace role doesn't expose anything extra.

So my overall approach would be:

Affected user -> REST GET item by ID -> 403?  => blocker is item lookup, not ReadData
Try item-specific MCP endpoint config for these users
Still blocked -> consumer workspace (only shared data) + Viewer role
Raise with Microsoft: item-shared users should work via MCP like via TDS

AI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.

This is an interesting case, especially since users can successfully query the same Lakehouse through Excel and the Fabric SQL endpoint without workspace-level access.

I would not assume that Read and ReadData permissions are insufficient. The MCP server may have an additional authorization requirement when resolving SQL endpoints through its generic all-databases interface.

Since you have already verified the item permissions and REST API access, I think this needs clarification from the Fabric MCP team.

One thing worth testing is whether the same user can query through an item-specific MCP endpoint. If that also fails, it would strengthen the case for a Microsoft-side issue.

I agree that requiring workspace-level access just to query an individual Lakehouse would be a significant limitation for least-privilege access.

This is obviously an AI-generated response. In fact, it's almost word-for-word the exact response that Copilot gave me.

Yes, I've verified that the users have the proper item permissions. In the specific testing case I have, the have Read permissions on the lakehouse and Read,ReadData permissions on the SQL analytics endpoint. This is sufficient for them to query the lakehouse via a SQL connection (also verified) and for them to login to the Fabric portal and see the lakehouse and SQL analytics endpoint and use the query interface in the portal.

I don't have any SQL granular permissions (the users don't need them), and I don't have any workspace permissions for these users (they don't need access to anything else in the workspace, nor do I want them to have access to anything else in the workspace).

I haven't ried the item-scoped endpoint because it doesn't fit my use case. I'm not going to create 50 different connectors in Claude for each possible lakehouse.

Does anyone at Microsoft know how the Fabric Data Warehouse MCP server (https://api.fabric.microsoft.com/v1/mcp/dataPlane/sqlEndpoint) actually works and what permissions it actually requires to run an SQL query?

HI philipadc​,

Have you had a chance to review the solution we shared earlier? If the issue persists, feel free to reply so we can help further.

Thank you.

Hi philipadc

I can't find a line on Learn that says item-level Read and ReadData is enough for this server. The page only says it runs as the signed-in user, and lists workspace role, item permissions and SQL permissions as the things to check when calls fail. So the docs don't settle it either way.

One test would show where the denial comes from. Sign in as an affected user in Visual Studio Code, add the global endpoint from that Learn page, and run a plain query through executeSQL, such as a SELECT TOP 1 on a table that user can read in Excel. If VS Code fails with the same "Insufficient permissions", it's the server and not the Claude connector. If it works, the difference is in how the connector gets its token.

Either way, open a support ticket with the exact request and response of the failing executeSQL call. The forum can't see what the server checks internally.