The SQL MCP Server in Microsoft's Data API builder validates tokens from Entra ID. It does not issue them, and a custom connector in claude.ai needs a server that can. So: not directly. Here is what has to sit in between, what is currently broken on that path, and what you still will not have once it works.
What the SQL MCP Server does, and what it leaves to you
Data API builder (DAB) is a resource server. Its authentication documentation describes inbound auth as one thing: SQL MCP Server can validate JSON Web Tokens (JWTs) issued by an OAuth provider (for example, Microsoft Entra ID). The client includes the token with each request, and SQL MCP Server validates it.
For everything else it sends you elsewhere: If your MCP client requires API keys or another non-JWT scheme, front SQL MCP Server with a gateway or proxy.
A remote connector in claude.ai expects the other half of that arrangement. Before the Connect button can send anyone to a login page, Claude has to discover an authorization server and register itself with it. Three pieces have to exist:
- Protected resource metadata (RFC 9728). Your 401 has to tell Claude where the authorization server is. Without it, Claude probes two well-known paths, finds nothing, and reports that it could not reach the server.
- A way for Claude to register as a client. Claude uses dynamic client registration or a Client ID Metadata Document. Entra ID supports neither, so either something in front of Entra does, or an administrator pastes a pre-registered client ID into the connector form.
- An authorization endpoint and a token endpoint that speak PKCE with S256 and are reachable from Anthropic's infrastructure.
DAB provides none of the three, and its documentation does not claim otherwise. Anthropic's side of the contract is on one page, Authentication for connectors, including the Entra-specific footnote: the MCP server URL has to be registered as an Application ID URI, on a domain your tenant has verified, or the token request fails.
The Microsoft way: API Management in front
Microsoft's own answer is Azure API Management (APIM). The post Building Claude-Ready Entra ID-Protected MCP Servers with Azure API Management from May 2025 lays it out: APIM sits between Claude and the MCP server, holds the OAuth conversation with Claude, and validates Entra tokens on the way through. The current APIM documentation on securing MCP servers covers token validation with a policy and points to sample repositories for protected resource metadata and client authorization. It is a supported pattern. It is also built from policies and samples, not from a checkbox.
Two more things come with it. Claude connects from Anthropic's infrastructure, not from the user's laptop, so the endpoint has to be reachable from Anthropic's published egress range. And if the database lives on-premises, something has to carry the request from APIM into your network: a tunnel, a VPN, or a self-hosted gateway.
The bill of materials, then:
- Data API builder with the SQL MCP Server enabled
- Azure API Management, with the OAuth policies configured and kept current
- An Entra app registration, with the server URL as an Application ID URI on a verified domain
- A public endpoint, reachable from Anthropic's IP range
- For an on-premises database, a tunnel or self-hosted gateway into your network
Five things somebody runs. None of them is exotic in an Azure house. All of them are yours from then on.
The part that is currently broken
Since early summer 2026, custom connectors that hand Claude off to Entra ID have been failing in one specific way. The login works. Entra logs a successful sign-in. Claude then never calls the token endpoint to exchange the authorization code, and the MCP server sees requests without an Authorization header. The user is told that authorization with the MCP server failed.
Two public issues document it. Issue #506, opened on 29 June 2026, covers a self-hosted server with a single-tenant Entra app, a confidential client, PKCE and spec-compliant metadata. Issue #632, opened on 16 July 2026, covers Microsoft's own first-party servers: Business Central, Power BI and Fabric, Microsoft 365. The same servers connect from Claude Code, from Claude Desktop through a local bridge, and from ChatGPT. Both issues are open as of this writing, and some public-client configurations reportedly work while identical-looking ones do not.
Whether the APIM route is affected depends on who Claude ends up talking to. If the metadata points Claude at Entra itself, the reports above apply. If APIM presents its own authorization server and hands out its own client registrations, you are on a different path, and you should test it end to end before you commit a team to it. None of this is a Microsoft problem. The bug sits at Anthropic, and every connector that fronts Entra depends on the same fix, ours included. If the issues close, this section becomes one sentence.
What you still will not have
Assume all of it works. APIM is in place, the token exchange is fixed, a controller signs into Claude with her Entra account and asks the SQL MCP Server for overdue invoices. Three things are still missing, and they are the reason this article exists.
Field masking
DAB's permission model can include or exclude columns per role. The authorization overview puts it plainly: You can configure which fields should be accessible for an action.
That is a switch. A customer number is either in the response or it is not. There is no way to show the last four digits, hash an email address, or pseudonymize a name so the model can group by it without reading it. If a field has to be usable and protected at the same time, DAB has no setting for that.
Who the database sees
DAB connects to SQL Server with one connection string: a SQL login or a managed identity. The person in Claude never reaches the database as themselves. DAB can forward the token's claims into the session through session context, and your own row-level security policies can read them. That is real, and it is T-SQL you write and maintain per table. The connection principal in the database's own audit stays the service identity either way. To the DBA reading the log, every employee is the same caller.
Audit
What exists is telemetry. Each tool call produces an OpenTelemetry span, exportable to Log Analytics or Application Insights, tagged with user.role, action.type and the data source. What does not exist is an audit log that answers "who asked which question, against which table, at what time". The spans carry a role, not a person. If compliance asks that question, you build the report from traces, provided the traces are still there.
The bill
Add it up. To get SSO into Claude for one SQL Server, you operate three Azure components, wait out or route around an open bug at Anthropic, and end up with hiding instead of masking, a service account instead of a person, and telemetry instead of an audit trail. That is "You could build this. Then you'd run it", with Microsoft parts instead of open source.
When the Microsoft way is right
Take it if you are an Azure house with APIM already in production, you have one database to connect, there is no personal data in the tables or no masking obligation on it, and your team can wait for the token issue to close. In that case DAB is free, production-ready and the right choice, and we say the same on our homepage.
Look further the moment PII sits in those tables, several roles need to see different shapes of the same data, or somebody has asked for an audit log per user. Those three requirements are exactly what the stack above does not produce, and no amount of APIM configuration adds them. Loopthink puts a connector in front of the same SQL MCP Server that Claude and ChatGPT accept as it is, runs every call as the person who asked, masks fields before the answer leaves your network, and logs each call under that person's name; the mechanics are in the whitepaper.
And if nobody in your company has connected anything yet, read the companion piece on what happens in the meantime: your ERP is already connected to ChatGPT, through CSV export.