[Bug]:Remote MCP server OAuth flow broken — AADSTS9010010: resource parameter conflicts with scope on v2.0 endpoint

Version

Remote Power BI MCP Server — https://api.fabric.microsoft.com/v1/mcp/powerbi

Model used

Claude Sonnet 4.6 (via GitHub Copilot CLI v1.0.2)

Description

The Remote Power BI MCP server's browser-based OAuth authentication flow stopped working around March 7–8, 2026. The authorization URL constructed by the server sends both a scope and a resource parameter on the OAuth v2.0 endpoint. This combination is invalid on v2.0 and now triggers AADSTS9010010 due to a Microsoft Entra ID enforcement change rolled out in early March 2026.

The v2.0 endpoint does not support the resource parameter (Microsoft docs). Azure AD previously tolerated this parameter silently, but stricter validation now rejects any request where resource conflicts with or duplicates the scope value.

The problematic authorization URL constructed by the server:

https://login.microsoftonline.com/common/oauth2/v2.0/authorize?
  response_type=code&
  client_id=aebc6443-996d-45c2-90f0-388ff96faa56&
  code_challenge=RLVE6Q5yxa2kgoIBUD1FN5_Y_PKqAA9C-cqW8C2ju7w&
  code_challenge_method=S256&
  redirect_uri=http://127.0.0.1:50389/&
  state=XOzIbjumFRWmQmrNu226Z8O29x6qt-dlakQ5MYOmISY&
  scope=https://analysis.windows.net/powerbi/api/.default&
  resource=https://api.fabric.microsoft.com/v1/mcp/powerbi

Parameter	Value	Issue
`scope`	`https://analysis.windows.net/powerbi/api/.default`	✅ Correct for v2.0
`resource`	`https://api.fabric.microsoft.com/v1/mcp/powerbi`	❌ Not supported in v2.0; mismatched resource

Expected Behavior

The server initiates the browser OAuth flow, the user authenticates successfully, and the MCP client connects to https://api.fabric.microsoft.com/v1/mcp/powerbi with a valid token.

The OAuth v2.0 authorization request should include only the scope parameter. The resource parameter must be removed from the request.

Actual Behavior

The browser redirect to Azure AD returns:

AADSTS9010010: The resource parameter provided in the request doesn't match with the requested scopes.

Authentication never completes, and the MCP client reports:

MCP error -32001: Request timed out

Reproduction steps:

Configure the Remote Power BI MCP server in any MCP client (no headers / pre-auth):

{
  "powerbi-remote": {
    "url": "https://api.fabric.microsoft.com/v1/mcp/powerbi",
    "type": "http"
  }
}

Attempt to connect — the server initiates the browser OAuth flow.
Browser shows the AADSTS9010010 error; authentication never completes.
MCP client reports: MCP error -32001: Request timed out

Additional Context

OS: Windows 11
Tenant: Microsoft corp (72f988bf-86f1-41af-91ab-2d7cd011db47)
Date broken: ~March 7–8, 2026 (worked fine the prior week)
Screenshot: [Screenshot 2026-03-09 154643.png] showing AADSTS9010010 in browser

I am seeing the same issue in one of my mcp servers. Does anyone know the solution?

Lei Liu (@lei-liu)

Hey Lei Liu (@lei-liu), the GitHub Copilot CLI update caused a bug where that error is shown .

It should be resolved now. I verified this morning with v1.0.5. You may need to update your GitHub CLI version (run /update with Copilot open).

Can you let me know if you're still seeing issues?

adriandsa

adriandsa is your issue also with the GitHub Copilot CLI and a separate MCP server?

Stephen Godderidge (@stephengodderidge)

Stephen Godderidge (@stephengodderidge) I am having exactly the same problem with the Dataverse MCP server for Github Copilot CLI ( 1.0.7), token expires after 1 hour and does not refresh correctly

Tools: AADSTS9010010: The resource parameter provided in the request doesn't match with the requested scopes.

I am having this error too, when testing oauth flow in the mcp inspector using . I want to add, when i use postman, it doesnt add the resource parameter and it works fine.

Stephen Godderidge (@stephengodderidge)

Adding concrete data from the Copilot CLI side.

Stephen Godderidge (@stephengodderidge) mentioned this was fixed in CLI v1.0.5, but Francisco Fernandez Coloma (@FranFdezColoma) and naqvir90 are still hitting it. I believe the root cause is server-side, not CLI-side.

We confirmed that the Power BI Remote server is the only MCP server (out of 7 configured) that triggers a browser auth prompt on every CLI session start. Tested by launching with --disable-mcp-server powerbi-remote — popup disappears completely.

Inspecting the CLI's cached OAuth metadata (~/.copilot/mcp-oauth-config/), the Power BI Remote server includes a resourceUrl field that other servers (e.g., Dataverse MCP) do not:

Field	Power BI Remote	Dataverse MCP
`resourceUrl`	`https://api.fabric.microsoft.com/v1/mcp/powerbi`	(not present)
`authorizationServerUrl`	`/common/v2.0`	`/<tenant-id>/v2.0`

This resourceUrl is what gets sent as the resource parameter in the v2.0 authorization URL — the direct cause of AADSTS9010010. The Dataverse MCP server omits this field and its auth works silently.

The CLI does cache a refresh token for Power BI (1,743 chars), but it appears the silent token refresh path also fails — likely because the refresh request includes the same invalid resource parameter — forcing a full browser flow every time.

Suggested fix: Remove resourceUrl from the Power BI Remote server's OAuth discovery response, matching the pattern used by Dataverse MCP.

Workaround: --disable-mcp-server powerbi-remote when launching the CLI.

Related: microsoft/mcp#1922 (tracking the startup prompt UX issue).

same problem here with claude desktop

Affected client: Claude Cowork (Anthropic desktop app)

Confirming this issue. When adding https://api.fabric.microsoft.com/v1/mcp/powerbi as a custom remote MCP connector in Claude Cowork, clicking Connect immediately returns "Couldn't reach the MCP server" — no sign-in prompt appears at all.

The tenant setting "Users can use the Power BI Model Context Protocol server endpoint (preview)" is enabled for the entire organization, so that's not the blocker.

Based on the diagnosis in this thread, the resourceUrl field in the OAuth discovery response is causing the auth flow to fail before it even reaches the sign-in step. This affects Claude Cowork users the same way it affects GitHub Copilot CLI users.

+1 on the fix: removing resourceUrl from the discovery response to match the Dataverse MCP pattern.

We are seeing the same issue in an integration with Amazon QuickSight and Azure AD (Entra ID).

QuickSight generates the authorize URL and includes both:

scope=api:///SH.ALL (v2 style)
resource= (v1 style)

against the /oauth2/v2.0/authorize endpoint, which results in:

AADSTS9010010: The resource parameter provided in the request doesn't match with the requested scopes

From what we can tell, this appears to be due to stricter validation in Azure AD, since the v2 endpoint expects scope and does not support resource in the same request. ()

The challenge is that we don’t control the final authorize URL—QuickSight constructs it internally—so we cannot remove the resource parameter.

Questions:

Has there been a recent enforcement change around rejecting resource + scope on v2 endpoints?
Is there any backward compatibility or mitigation planned for third-party tools that still send resources?
Any recommended approach for integrations where the OAuth request cannot be fully controlled?

This seems like a broader compatibility issue affecting tools that haven’t fully migrated to pure v2 semantics.

Confirming we're hitting this too. First-time setup, never worked for us. Tenant setting is enabled.

Connecting from the claude.ai connector against https://api.fabric.microsoft.com/v1/mcp/powerbi gives us one of two errors:

Couldn't connect Microsoft Power BI — Failed to generate authorization URL
Couldn't reach the MCP server

Any ETA on a fix or workaround?

Hitting the same AADSTS9010010 error connecting Claude.ai (web) to a Fabric Data Agent MCP endpoint - not just Power BI MCP. Same root cause: resource parameter on Entra v2 endpoint.
Endpoint pattern: https://api.fabric.microsoft.com/v1/mcp/workspaces/{id}/dataagents/{id}/agent

Confirming same issue connecting ChatGPT Enterprise (custom MCP connector) to https://api.fabric.microsoft.com/v1/mcp/powerbi. Tenant setting is enabled, Fabric Trial workspace configured, app registration correct. Connector creation succeeds but OAuth fails with AADSTS9010010. +1 on removing resourceUrl from the OAuth discovery response.

Confirmed same issue still occurring in Claude Desktop when attempting to authenticate to the PowerBI MCP server: https://api.fabric.microsoft.com/v1/mcp/powerbi. I receive the AADSTS9010010 error.

Also confirming this is still an issue. Tried this in ChatGPT, Codex and Claude.

Strangely using VScode and GitHub copilot works fine but not the external clients

Confirm also have the same issue with Claude Desktop on my end trying to connect to Power BI service

+1

Quick update: unfortunately, the fix took a little longer than expected. It is now rolling out and is expected to be fully deployed to production by the end of next week (July 18).

I'll update this issue once the rollout is complete.

The fix has now been fully deployed, and the Power BI MCP should work correctly with external clients.

Please follow the guidance in the documentation: https://learn.microsoft.com/en-us/power-bi/developer/mcp/remote-mcp-server-external-clients

Confirmed it's now working for me. Much appreciated.

Rui Romano (@RuiRomano)

Hello Rui Romano (@RuiRomano),

I confirm this works on windows machine.

But I tried to use the MCP on mac, this was my mcp.json :
{ "servers": { "powerbi-remote": { "type": "http", "url": "https://api.fabric.microsoft.com/v1/mcp/powerbi" } } }

and I still get the same issues :
2026-07-27 11:36:41.137 [info] Starting server powerbi-remote
2026-07-27 11:36:41.138 [info] Connection state: Starting
2026-07-27 11:36:41.138 [info] Starting server from LocalProcess extension host
2026-07-27 11:36:41.138 [info] Connection state: Running
2026-07-27 11:36:41.243 [info] Discovered resource metadata at https://api.fabric.microsoft.com/.well-known/oauth-protected-resource/v1/mcp/powerbi
2026-07-27 11:36:41.243 [info] Using auth server metadata url: https://login.microsoftonline.com/organizations/v2.0
2026-07-27 11:36:41.481 [warning] Error fetching authorization server metadata: Error: Failed to fetch authorization server metadata from https://login.microsoftonline.com/.well-known/oauth-authorization-server/organizations/v2.0: 404
2026-07-27 11:36:41.482 [warning] Error fetching authorization server metadata: Error: Failed to fetch authorization server metadata from https://login.microsoftonline.com/.well-known/openid-configuration/organizations/v2.0: 404
2026-07-27 11:36:41.482 [info] Discovered authorization server metadata at https://login.microsoftonline.com/organizations/v2.0/.well-known/openid-configuration
2026-07-27 11:36:46.140 [info] Waiting for server to respond to initialize request...
2026-07-27 11:36:51.140 [info] Waiting for server to respond to initialize request...
2026-07-27 11:36:56.141 [info] Waiting for server to respond to initialize request...
2026-07-27 11:37:01.140 [info] Waiting for server to respond to initialize request...
2026-07-27 11:37:03.425 [warning] Error getting token from server metadata: ServerError: invalid_target: Error(s): 9010010 - Timestamp: 2026-07-27 09:37:03Z - Description: AADSTS9010010: The resource parameter provided in the request doesn't match with the requested scopes.

By adding the token to the mcp configuration this works fine, but without the token in the config it gives that error.
Could you confirm this please, thanks for helping us.

Regards

Rui Romano (@RuiRomano)

Cross-posting because this looks like the same root cause hitting a different Microsoft first-party MCP server: Dataverse MCP.

We're seeing an identical failure pattern connecting claude.ai's custom connector to the Dataverse MCP remote endpoint (https://<org>.crm.dynamics.com/api/mcp): the connector fails with a generic "Authorization with the MCP server failed" + ofid_ reference, while Entra sign-in logs show the underlying auth attempt succeeding cleanly every time (errorCode: 0, MFA satisfied).

We dug into it and confirmed the app registration, delegated permissions (mcp.tools + user_impersonation, both tenant-consented), redirect URI, and Allowed MCP Clients entry are all correctly configured — and a token minted directly for the same app registration authenticates against /api/mcp with a clean 200 OK. So the failure is specific to the claude.ai connector's OAuth handshake against Entra, not our tenant config.

This matches the diagnosis already filed against the Dataverse MCP repo: microsoft/Dataverse-MCP#15 — the server's OAuth Protected Resource Metadata advertises a resource value (https://<org>.crm.dynamics.com/api/mcp, with the path) that doesn't match where the Dynamics CRM scopes are actually registered in Entra (https://<org>.crm.dynamics.com, without the path) — causing AADSTS9010010 for spec-compliant remote clients, same shape as the bug here.

That repo appears to be an unmonitored labs repo (no Microsoft response since March), so flagging it here since Rui Romano (@RuiRomano) is clearly engaged on the underlying Entra v2.0 resource+scope enforcement change for Power BI/Fabric. Given it's hit at least three first-party MCP servers now (Power BI, Fabric Data Agents, Dataverse), is there a chance the fix being rolled out for Power BI MCP also covers Dataverse, or does that need separate engineering attention?

Cross-posting because this looks like the same root cause hitting a different Microsoft first-party MCP server: Dataverse MCP.

We're seeing an identical failure pattern connecting claude.ai's custom connector to the Dataverse MCP remote endpoint (https://<org>.crm.dynamics.com/api/mcp): the connector fails with a generic "Authorization with the MCP server failed" + ofid_ reference, while Entra sign-in logs show the underlying auth attempt succeeding cleanly every time (errorCode: 0, MFA satisfied).

We dug into it and confirmed the app registration, delegated permissions (mcp.tools + user_impersonation, both tenant-consented), redirect URI, and Allowed MCP Clients entry are all correctly configured — and a token minted directly for the same app registration authenticates against /api/mcp with a clean 200 OK. So the failure is specific to the claude.ai connector's OAuth handshake against Entra, not our tenant config.

This matches the diagnosis already filed against the Dataverse MCP repo: microsoft/Dataverse-MCP#15 — the server's OAuth Protected Resource Metadata advertises a resource value (https://<org>.crm.dynamics.com/api/mcp, with the path) that doesn't match where the Dynamics CRM scopes are actually registered in Entra (https://<org>.crm.dynamics.com, without the path) — causing AADSTS9010010 for spec-compliant remote clients, same shape as the bug here.

That repo appears to be an unmonitored labs repo (no Microsoft response since March), so flagging it here since @RuiRomano is clearly engaged on the underlying Entra v2.0 resource+scope enforcement change for Power BI/Fabric. Given it's hit at least three first-party MCP servers now (Power BI, Fabric Data Agents, Dataverse), is there a chance the fix being rolled out for Power BI MCP also covers Dataverse, or does that need separate engineering attention?

+1

Seeing this same AADSTS9010010 reproduce today (2026-08-20) against https://api.fabric.microsoft.com/v1/mcp/powerbi, both from VS Code's own native MCP client (the documented, first-party path) and from a fully custom OAuth client, across two different Entra tenants. Posting the details in case it helps narrow down the root cause.

Repro #1: VS Code native MCP client (first-party, as documented)

Installed via the one-click installer from the [remote MCP server docs](https://learn.microsoft.com/en-us/power-bi/developer/mcp/remote-mcp-server-get-started), no custom app registration involved — VS Code handles the OAuth client itself.

Discovered resource metadata at https://api.fabric.microsoft.com/.well-known/oauth-protected-resource/v1/mcp/powerbi
Using auth server metadata url: https://login.microsoftonline.com/organizations/v2.0
Error fetching authorization server metadata: Error: Failed to fetch authorization server metadata from https://login.microsoftonline.com/.well-known/oauth-authorization-server/organizations/v2.0: 404
Error fetching authorization server metadata: Error: Failed to fetch authorization server metadata from https://login.microsoftonline.com/.well-known/openid-configuration/organizations/v2.0: 404
Discovered authorization server metadata at https://login.microsoftonline.com/organizations/v2.0/.well-known/openid-configuration
Waiting for server to respond to `initialize` request...
Error getting token from server metadata: ServerError: invalid_target: Error(s): 9010010 - Description: AADSTS9010010: The resource parameter provided in the request doesn't match with the requested scopes.
Trace ID: 48401131-6b37-4000-88d2-086d22713101
Correlation ID: 5500e6ce-7c4a-45a3-a31e-1bcb50252a8e
Timestamp: 2026-08-20 08:40:54Z
Connection state: Error 401 status sending message to https://api.fabric.microsoft.com/v1/mcp/powerbi: {"requestId":"5b00a687-873a-4078-876b-383caa145bdd","errorCode":"TokenIsMissing","message":"Access token is required","isRetriable":false}

Because the token request itself fails with AADSTS9010010 (mixing resource and scope against the v2.0 token endpoint — same shape as the original report in this issue), the server never receives a token at all, hence TokenIsMissing.

Repro #2: Custom OAuth client (mcp-remote and a plain MSAL/httpx client)

Separately, using a custom Entra app registration (Delegated permissions Item.Read.All + Item.Execute.All, admin consent granted, "Users can use the Power BI Model Context Protocol server endpoint (preview)" tenant setting enabled), the token request itself succeeds (presumably because these clients send scope=.../.default without a conflicting resource param, or Entra tolerates it), but the very first initialize call to the MCP endpoint is rejected:

POST https://api.fabric.microsoft.com/v1/mcp/powerbi
Authorization: Bearer <valid delegated token>

401
WWW-Authenticate: Bearer error="invalid_request", resource_metadata="https://api.fabric.microsoft.com/.well-known/oauth-protected-resource/v1/mcp/powerbi"
Body: {"error":{"code":-32600,"message":"Unable to process the request","data":{"errorCode":"","requestId":"a17173be-70ba-4bdd-93de-bcea99aa3da9"}},"jsonrpc":"2.0","id":0}

Decoded token claims for that request:

{
  "aud": "https://analysis.windows.net/powerbi/api",
  "idtyp": "user",
  "scp": "Item.Execute.All Item.Read.All",
  "upn": "<redacted>",
  "tid": "<redacted>"
}

This exact invalid_request / -32600 "Unable to process the request" response reproduced identically across:

2 different Entra tenants
3 different user accounts (all confirmed licensed, with Build/Admin access on the target workspace)
2 different OAuth client implementations (mcp-remote with --static-oauth-client-info, and a plain Python/MSAL/httpx client)
Both before and >15 minutes after enabling the tenant setting

Some of the other requestIds collected across attempts, in case they're useful for correlating server-side logs: 20d04310-c836-4dd8-83bc-c110fc120d90, 9978ec20-0314-4f16-be7b-4abe603dec42 (this one returned FeatureNotAvailable before the tenant setting was enabled — so the endpoint clearly does distinguish that case from the generic invalid_request one above).

Question

Given the native VS Code client (first-party, documented path) fails with the same resource/scope conflict described in this issue, is this a live regression on the authorization-server-metadata / token-request side for the /v1/mcp/powerbi endpoint under the organizations (multi-tenant) authority? And separately, is the generic invalid_request / -32600 response on initialize (repro #2, where a valid delegated token is successfully obtained) expected to mean something specific — malformed request, unsupported client, or something else — since the error code/message don't indicate what's actually wrong?

Happy to provide more logs/traces if useful.

Another data point: `403 FeatureNotAvailable` independent of the OAuth `resource` bug

Adding evidence from a Google Gemini Enterprise integration, because I think there are two separate failures being conflated in this thread. The resourceUrl / AADSTS9010010 issue is real, but it is
not the only thing broken on /v1/mcp/powerbi.

Setup

Single-tenant Entra app registration (Web platform, client secret), delegated Power BI Service permissions, all admin-consented:

App.Read.All, Catalog.Read.All, Dataset.Read.All, MLModel.Execute.All, Report.Read.All, Workspace.Read.All
plus Microsoft Graph User.Read

Configured in Gemini Enterprise as a Custom MCP Server data store:

Field	Value
MCP Server URL	`https://api.fabric.microsoft.com/v1/mcp/powerbi`
Authorization URL	`https://login.microsoftonline.com/<tenant>/oauth2/v2.0/authorize`
Token URL	`https://login.microsoftonline.com/<tenant>/oauth2/v2.0/token`
Scopes	`https://analysis.windows.net/powerbi/api/.default offline_access`
PKCE	enabled

OAuth completes successfully. "Verify Auth" returns Successfully logged in with associated identity: <user>@<tenant>. The connector shows as authenticated.

Tool discovery then fails. Gemini Enterprise's RefreshDataConnectorTools returns gRPC code 9 FAILED_PRECONDITION ("Precondition check failed"), surfaced in the UI as "Failed to reload custom actions".
No tools are ever imported, so the agent has no actions to call.

Isolating it outside any MCP client

To rule out the client, I minted delegated tokens directly and called initialize by hand — no OAuth authorize step, therefore no resource parameter involved at all:

TOKEN=$(az account get-access-token --resource https://api.fabric.microsoft.com --query accessToken -o tsv)
curl -s -w "\nHTTP %{http_code}\n" -X POST https://api.fabric.microsoft.com/v1/mcp/powerbi \
  -H "Authorization: Bearer $TOKEN" \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -H 'MCP-Protocol-Version: 2025-06-18' \
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-06-18","capabilities":{},"clientInfo":{"name":"probe","version":"1"}}}'

Result:

{"error":{"code":-32003,"message":"The feature is not available",
 "data":{"errorCode":"FeatureNotAvailable","requestId":"51800004-7104-4794-ae46-ba1ac6ff9e41"}},
 "jsonrpc":"2.0","id":1}
HTTP 403

Endpoint matrix — same token, same tenant, same user, same minute

┌───────────────────────────────────────────────────────────────────────┬──────────────────────────────────────────┐
│                               Endpoint                                │                  Result                  │
├───────────────────────────────────────────────────────────────────────┼──────────────────────────────────────────┤
│ https://api.fabric.microsoft.com/v1/mcp                               │ 200 — FabricMCPServer 13.0.28512.429     │
├───────────────────────────────────────────────────────────────────────┼──────────────────────────────────────────┤
│ https://api.fabric.microsoft.com/v1/mcp/core                          │ 200 — 29 tools returned                  │
├───────────────────────────────────────────────────────────────────────┼──────────────────────────────────────────┤
│ https://api.fabric.microsoft.com/v1/mcp/dataPlane/kqlEndpoint         │ 200 — microsoft.fabric.kqlEndpoint 0.1.0 │
├───────────────────────────────────────────────────────────────────────┼──────────────────────────────────────────┤
│ https://api.fabric.microsoft.com/v1/mcp/fabricaihub/integrations/m365 │ 200                                      │
├───────────────────────────────────────────────────────────────────────┼──────────────────────────────────────────┤
│ https://api.fabric.microsoft.com/v1/mcp/powerbi                       │ 403 FeatureNotAvailable                  │
├───────────────────────────────────────────────────────────────────────┼──────────────────────────────────────────┤
│ https://api.fabric.microsoft.com/v1/mcp/dataPlane/sqlEndpoint         │ 403 FeatureNotAvailable                  │
└───────────────────────────────────────────────────────────────────────┴──────────────────────────────────────────┘

Only the two data-query surfaces are refused. Control-plane and KQL surfaces work fine with the very same bearer token.

Variables ruled out

┌──────────────────────┬──────────────────────────────────────────────────────────────────────────────┬───────────────────────────────┐
│       Variable       │                                    Tested                                    │            Outcome            │
├──────────────────────┼──────────────────────────────────────────────────────────────────────────────┼───────────────────────────────┤
│ Token audience       │ https://api.fabric.microsoft.com vs https://analysis.windows.net/powerbi/api │ 403 both                      │
├──────────────────────┼──────────────────────────────────────────────────────────────────────────────┼───────────────────────────────┤
│ Client app           │ Azure CLI (04b07795-…) vs VS Code (aebc6443-996d-45c2-90f0-388ff96faa56)     │ 403 both                      │
├──────────────────────┼──────────────────────────────────────────────────────────────────────────────┼───────────────────────────────┤
│ OAuth resource param │ Absent entirely (direct token, no authorize call)                            │ Still 403                     │
├──────────────────────┼──────────────────────────────────────────────────────────────────────────────┼───────────────────────────────┤
│ Endpoint path        │ see matrix above                                                             │ Only data-query surfaces fail │
└──────────────────────┴──────────────────────────────────────────────────────────────────────────────┴───────────────────────────────┘

The VS Code result matters: using Microsoft's own first-party client ID via device code, against the same tenant and user, still returns 403 FeatureNotAvailable.

Separately, installing the documented Power BI MCP server in VS Code produces an authorize URL that does carry the conflicting parameter —

scope=https://analysis.windows.net/powerbi/api/.default openid profile offline_access
resource=https://api.fabric.microsoft.com/v1/mcp/powerbi

— against /organizations/oauth2/v2.0/authorize. Sign-in itself succeeds ("You can close this window now"), but the session never establishes and VS Code re-prompts on a new loopback port every attempt,
consistent with @ericchansen's finding that silent refresh fails because the refresh request replays the same invalid resource. So even the reference client cannot complete a working session here.

Underlying Power BI REST APIs are healthy for this identity — GET /v1.0/myorg/groups returns 8 workspaces, GET /v1.0/myorg/reports/{id} resolves fine. It is specifically the MCP data-query surfaces that refuse.

Questions

1. What exactly does FeatureNotAvailable gate on /v1/mcp/powerbi and /v1/mcp/dataPlane/sqlEndpoint? Is it solely the tenant setting "Users can use the Power BI Model Context Protocol server endpoint (preview)",
or is there an additional flag, capacity requirement, or regional rollout condition? (Our home cluster is wabi-us-east2.)
2. @AviHack reported this same endpoint failing with that tenant setting enabled org-wide — so the setting alone appears insufficient. What else is checked?
3. Is /v1/mcp/dataPlane/sqlEndpoint gated by the same flag as /v1/mcp/powerbi? They fail identically, which suggests one shared switch over data-query surfaces.
4. Can the 403 response include which precondition failed? Right now every downstream client renders it as an opaque error — Gemini Enterprise turns it into FAILED_PRECONDITION with no detail, which cost us a
week of debugging in the wrong layer.

Happy to supply request IDs, timestamps, or run further probes. Tenant and account details available privately if useful.

I'm having the same AADSTS9010010 failure on the Fabric Data Warehouse MCP endpoint (https://api.fabric.microsoft.com/v1/mcp/dataPlane/sqlEndpoint), reproduced from VS Code stable (built-in MCP client) and claude.ai custom connectors on 2026-09-01.

VS Code log excerpt:

Discovered resource metadata at https://api.fabric.microsoft.com/.well-known/oauth-protected-resource/v1/mcp/dataPlane/sqlEndpoint
Error getting token: ServerError: invalid_target: AADSTS9010010: The resource parameter provided in the request doesn't match with the requested scopes.
Trace ID: e1deb430-c3cf-4236-91fd-58026e5d1f00
Correlation ID: b40a5f3c-6c90-47de-920d-55774d1b3db4
→ 401 {"errorCode":"TokenIsMissing"}

Note: the Core endpoint (/v1/mcp/core) authenticates fine with the same identity and app registration — only the dataPlane/sqlEndpoint metadata triggers the mismatch.

I'm having the same AADSTS9010010 failure on the Fabric Data Warehouse MCP endpoint (https://api.fabric.microsoft.com/v1/mcp/dataPlane/sqlEndpoint), reproduced from VS Code stable (built-in MCP client) and claude.ai custom connectors on 2026-09-01.

VS Code log excerpt:

Discovered resource metadata at https://api.fabric.microsoft.com/.well-known/oauth-protected-resource/v1/mcp/dataPlane/sqlEndpoint Error getting token: ServerError: invalid_target: AADSTS9010010: The resource parameter provided in the request doesn't match with the requested scopes. Trace ID: e1deb430-c3cf-4236-91fd-58026e5d1f00 Correlation ID: b40a5f3c-6c90-47de-920d-55774d1b3db4 → 401 {"errorCode":"TokenIsMissing"}

Note: the Core endpoint (/v1/mcp/core) authenticates fine with the same identity and app registration — only the dataPlane/sqlEndpoint metadata triggers the mismatch.

Hey can you check if this is enabled from the admin portal, mine was fixed after enabling "Use POWERBI MCP" from PowerBI Admin dashboard.
Check Fabric Data Warehouse Admin Portal, you might have a clue there!!

URL : https://app.fabric.microsoft.com/admin-portal?experience=fabric-developer

I'm having the same AADSTS9010010 failure on the Fabric Data Warehouse MCP endpoint (https://api.fabric.microsoft.com/v1/mcp/dataPlane/sqlEndpoint), reproduced from VS Code stable (built-in MCP client) and claude.ai custom connectors on 2026-09-01.
VS Code log excerpt:
Discovered resource metadata at https://api.fabric.microsoft.com/.well-known/oauth-protected-resource/v1/mcp/dataPlane/sqlEndpoint Error getting token: ServerError: invalid_target: AADSTS9010010: The resource parameter provided in the request doesn't match with the requested scopes. Trace ID: e1deb430-c3cf-4236-91fd-58026e5d1f00 Correlation ID: b40a5f3c-6c90-47de-920d-55774d1b3db4 → 401 {"errorCode":"TokenIsMissing"}
Note: the Core endpoint (/v1/mcp/core) authenticates fine with the same identity and app registration — only the dataPlane/sqlEndpoint metadata triggers the mismatch.

Hey can you check if this is enabled from the admin portal, mine was fixed after enabling "Use POWERBI MCP" from PowerBI Admin dashboard. Check Fabric Data Warehouse Admin Portal, you might have a clue there!!

URL : https://app.fabric.microsoft.com/admin-portal?experience=fabric-developer

Thanks for the tip, but I had no luck with that approach. When I access Admin portal > Tenant settings > I can only see Fabric MCP access, which is the current group my account belongs to, and has access. Would you mind sharing your setup on this page, maybe with a screen cap? Feel free to DM me as well.

Faced same issue with entra and MCP login for our MCP gateway. Fix adding the exact URL your MCP client (.i.e, claude, VS Code, etc) sending in resource query param to the entra registered app's manifest's identifierUris as below:

"identifierUris": [ "", "" ]

Navigation Menu

Repository navigation

[Bug]:Remote MCP server OAuth flow broken — AADSTS9010010: `resource` parameter conflicts with `scope` on v2.0 endpoint #68

Version

Model used

Description

Expected Behavior

Actual Behavior

Additional Context

17 remaining items

Repro #1: VS Code native MCP client (first-party, as documented)

Repro #2: Custom OAuth client (mcp-remote and a plain MSAL/httpx client)

Question

Another data point: `403 FeatureNotAvailable` independent of the OAuth `resource` bug

Setup

Isolating it outside any MCP client

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Bug]:Remote MCP server OAuth flow broken — AADSTS9010010: resource parameter conflicts with scope on v2.0 endpoint #68

Description

Version

Model used

Description

Expected Behavior

Actual Behavior

Additional Context

Activity

adriandsa commented on Mar 12, 2026

stephengodderidge commented on Mar 16, 2026

stephengodderidge commented on Mar 16, 2026

FranFdezColoma commented on Mar 18, 2026

naqvir90 commented on Mar 19, 2026

ericchansen commented on Mar 20, 2026

mfernandezfidesol commented on Mar 23, 2026

AviHack commented on Mar 31, 2026

drathore-upland commented on Apr 2, 2026

LlewellynS96 commented on Apr 19, 2026

isabellec23 commented on Apr 28, 2026

AbdullahShareef79 commented on Apr 29, 2026

dshaverPIH commented on May 4, 2026

17 remaining items

abeckett86 commented on Jun 30, 2026

CarlOhlsson commented on Jun 30, 2026

stefandesmet09 commented on Jul 1, 2026

RuiRomano commented on Jul 8, 2026

RuiRomano commented on Jul 20, 2026

Simon-SBOX commented on Jul 20, 2026

abdelilahNaitBenamer commented on Jul 27, 2026

tsileo-wdi commented on Aug 2, 2026

mfernandezfidesol commented on Aug 3, 2026

jcozar87 commented on Aug 20, 2026

Repro #1: VS Code native MCP client (first-party, as documented)

Repro #2: Custom OAuth client (mcp-remote and a plain MSAL/httpx client)

Question

mohitsingh-techo commented on Aug 21, 2026

Another data point: 403 FeatureNotAvailable independent of the OAuth resource bug

Setup

Isolating it outside any MCP client

philipedoughty commented on Sep 2, 2026

mohitsingh-techo commented on Sep 2, 2026

philipedoughty commented on Sep 10, 2026

harsha0x3 commented on Oct 22, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

[Bug]:Remote MCP server OAuth flow broken — AADSTS9010010: `resource` parameter conflicts with `scope` on v2.0 endpoint #68

Another data point: `403 FeatureNotAvailable` independent of the OAuth `resource` bug