Execute SQL command doesn't reach server.

### MCP server URL

https://dbassistant.nmbrstools.com/mcp

### Where does the issue occur?

During a conversation (after initial auth)

### Transport used

streamable-http

### Client registration type

Static

### SSE only: Does your server return the expected status code for POST requests?

Not applicable (my server does not use SSE)

### When did you last reproduce this?

2026/08/31 17:37

### Browser and OS

_No response_

### Describe the issue

Support report — custom connector tool calls blocked before reaching server

Connector: Peak AI Test (also shown as "Peak AI Data Assistant" in some screens)
URL: https://dbassistant.nmbrstools.com/mcp
Plan: Claude Team
Auth type: OAuth, Individual sign-in, via a custom Microsoft Entra ID App Registration (Client ID 88355db7-ce4b-4181-aa56-ef7168e96635, tenant 211667a5-759e-4e81-8df6-b5ff1899c9a7)

Summary

OAuth authorization completes successfully and one tool (get_knowledge_base) works reliably. The other four tools on this same connector — execute_sql, execute_sql_featureshop, export_query, export_query_featureshop — always fail with:

"This connector requires additional permissions. The user needs to reconnect it with the appropriate access."

Our server-side logs prove this failure happens before any HTTP request reaches our server — there is no corresponding log entry at all for these specific tool calls, while get_knowledge_base calls in the same session are logged and succeed every time. This points to a gate inside Claude's own platform, specific to these four tools, that we cannot see or control from our side.

Timeline

Phase 1 (resolved): OAuth authorization itself was initially failing outright ("Authorization with Peak AI Data Assistant failed", various Entra Trace IDs). We diagnosed and fixed, in order: a missing requiredResourceAccess declaration on the App Registration, an incorrectly-formatted scope in our protected resource metadata, and a mismatch between our configured token audience and the actual aud claim Entra issues (bare Client ID vs. Application ID URI). We also found and fixed an outdated fastmcp/mcp server library that hard-rejected the MCP protocol version Claude's client sends (2026-07-28) instead of negotiating down. All of this is now confirmed working — OAuth completes, and get_knowledge_base succeeds consistently.

Phase 2 (current, unresolved): With OAuth now working, the four SQL/export tools still cannot be called at all. This is a distinct failure from Phase 1 — it is not an authorization problem (the token is valid, since get_knowledge_base uses the exact same token/session and works).

What we've verified, to rule out our own configuration
Connector tool permissions: confirmed all 5 tools (including the 4 failing ones) are set to "Always allow" in the connector's Configuration tab.
Server-side auth logic: our server applies identical authentication middleware to every /mcp request regardless of which tool is being invoked — there is no tool-specific auth check in our code that could explain a difference between tools.
MCP tool annotations: added standards-compliant readOnlyHint: true (and destructiveHint: false, idempotentHint: true, openWorldHint: false) to all 5 tools, in case a client-side heuristic was treating unannotated, action-sounding tool names (execute_sql, export_query) as higher-risk. Confirmed via a full local simulated MCP handshake that these annotations are correctly present in our tools/list response. This did not change the outcome.
Reproduced identically two ways: both via a separate Claude session with direct tool access, and via the actual production claude.ai chat — same failure, same "zero request received" result, every time.
Evidence
get_knowledge_base calls: consistently produce a logged POST /mcp request and a 200 OK response.
execute_sql (and the other 3 tools) calls: no corresponding log entry at all, checked immediately after each failed attempt, across more than a dozen attempts on multiple deploys.
Reference IDs collected from the "needs additional permissions" failures (Phase 2, current issue): ofid_6b7a4c9faf069312, ofid_b5a1f59a85ba06cf, ofid_cbd4ab1053ff3ac6, ofid_766c3dce7442b236, ofid_ee26c1c9ab16bda5.
Entra Trace IDs from the earlier, now-resolved Phase 1 authorization issue (included for completeness, not believed to be relevant to the current problem): de03d461-a8f6-477f-8b8a-901139374000, 74469b61-1833-407e-8ddb-c3c46bf74700, 2ec020d8-6e15-4ed4-822b-5173c4435900.
What we're asking

Can you tell us why calls to these four specific tools are being blocked before reaching our server, when the connector's own tool-permission settings show them as fully allowed and the identical auth token/session works fine for get_knowledge_base? Is there a tool-name-based heuristic, a scope requirement, or some other client-side gate we're not aware of that we could address on our end?

### Issue details

```shell
Support report — custom connector tool calls blocked before reaching server

Connector: Peak AI Test (also shown as "Peak AI Data Assistant" in some screens)
URL: https://dbassistant.nmbrstools.com/mcp
Plan: Claude Team
Auth type: OAuth, Individual sign-in, via a custom Microsoft Entra ID App Registration (Client ID 88355db7-ce4b-4181-aa56-ef7168e96635, tenant 211667a5-759e-4e81-8df6-b5ff1899c9a7)

Summary

OAuth authorization completes successfully and one tool (get_knowledge_base) works reliably. The other four tools on this same connector — execute_sql, execute_sql_featureshop, export_query, export_query_featureshop — always fail with:

"This connector requires additional permissions. The user needs to reconnect it with the appropriate access."

Our server-side logs prove this failure happens before any HTTP request reaches our server — there is no corresponding log entry at all for these specific tool calls, while get_knowledge_base calls in the same session are logged and succeed every time. This points to a gate inside Claude's own platform, specific to these four tools, that we cannot see or control from our side.

Timeline

Phase 1 (resolved): OAuth authorization itself was initially failing outright ("Authorization with Peak AI Data Assistant failed", various Entra Trace IDs). We diagnosed and fixed, in order: a missing requiredResourceAccess declaration on the App Registration, an incorrectly-formatted scope in our protected resource metadata, and a mismatch between our configured token audience and the actual aud claim Entra issues (bare Client ID vs. Application ID URI). We also found and fixed an outdated fastmcp/mcp server library that hard-rejected the MCP protocol version Claude's client sends (2026-07-28) instead of negotiating down. All of this is now confirmed working — OAuth completes, and get_knowledge_base succeeds consistently.

Phase 2 (current, unresolved): With OAuth now working, the four SQL/export tools still cannot be called at all. This is a distinct failure from Phase 1 — it is not an authorization problem (the token is valid, since get_knowledge_base uses the exact same token/session and works).

What we've verified, to rule out our own configuration
Connector tool permissions: confirmed all 5 tools (including the 4 failing ones) are set to "Always allow" in the connector's Configuration tab.
Server-side auth logic: our server applies identical authentication middleware to every /mcp request regardless of which tool is being invoked — there is no tool-specific auth check in our code that could explain a difference between tools.
MCP tool annotations: added standards-compliant readOnlyHint: true (and destructiveHint: false, idempotentHint: true, openWorldHint: false) to all 5 tools, in case a client-side heuristic was treating unannotated, action-sounding tool names (execute_sql, export_query) as higher-risk. Confirmed via a full local simulated MCP handshake that these annotations are correctly present in our tools/list response. This did not change the outcome.
Reproduced identically two ways: both via a separate Claude session with direct tool access, and via the actual production claude.ai chat — same failure, same "zero request received" result, every time.
Evidence
get_knowledge_base calls: consistently produce a logged POST /mcp request and a 200 OK response.
execute_sql (and the other 3 tools) calls: no corresponding log entry at all, checked immediately after each failed attempt, across more than a dozen attempts on multiple deploys.
Reference IDs collected from the "needs additional permissions" failures (Phase 2, current issue): ofid_6b7a4c9faf069312, ofid_b5a1f59a85ba06cf, ofid_cbd4ab1053ff3ac6, ofid_766c3dce7442b236, ofid_ee26c1c9ab16bda5.
Entra Trace IDs from the earlier, now-resolved Phase 1 authorization issue (included for completeness, not believed to be relevant to the current problem): de03d461-a8f6-477f-8b8a-901139374000, 74469b61-1833-407e-8ddb-c3c46bf74700, 2ec020d8-6e15-4ed4-822b-5173c4435900.
What we're asking

Can you tell us why calls to these four specific tools are being blocked before reaching our server, when the connector's own tool-permission settings show them as fully allowed and the identical auth token/session works fine for get_knowledge_base? Is there a tool-name-based heuristic, a scope requirement, or some other client-side gate we're not aware of that we could address on our end?
```

### Expected behavior

Expected behavior is that when the user connects to the connector, it goes through authentication, that works already. After authenticated and connected, when the user asks data questions, the connector deploys execute_sql action with credentials in the server. Instead it asks to re-authenticate to perform this action, then fails to connect. This never reaches the server side even.

### Logs from your server

```shell
I don't have access to server-side logs — I only see what the tool call itself returns, and that was just this error message, verbatim, both times I tried:

This connector requires additional permissions. The user needs to reconnect it with the appropriate access.

There's no stack trace, request ID, or additional detail behind that on my end — it's the full error payload the MCP connector (Peak AI Test) returned. If you need actual server-side logs (e.g., from the dbassistant.nmbrstools.com MCP service), that'd have to come from wherever that service's logs are hosted — Azure App Service logs, Application Insights, etc., depending on how it's deployed. I can't reach those from here.
```

### Additional context

_No response_