Support explicit OAuth authorization when MCP initialization succeeds anonymously

We need to let an operator explicitly authorize an MCP server before invoking any tools.

This request comes from netclaw-dev/netclaw#2123.

The original report reproduced the behavior against Google's official Google Docs MCP server and Google Drive MCP server:

• Docs: https://docsmcp.googleapis.com/mcp/v1
• Drive: https://drivemcp.googleapis.com/mcp/v1

Both servers allowed anonymous MCP initialization and tool discovery. Netclaw's explicit authorization command therefore reached no OAuth callback and failed.

We then built the standalone reproduction below with the unmodified MCP C# SDK. Its local server models anonymous discovery with protected tool operations. The spike does not perform a live Google OAuth exchange.

With SDK 2.2.0, initialization and discovery succeed without invoking AuthorizationCallbackHandler. I could not find a public API that explicitly starts the SDK OAuth flow.

Reproduction

Standalone reproduction repository, revision 55cc2c9.

Environment:

• MCP C# SDK 2.2.0
• .NET SDK 10.0.400
• Linux
• Streamable HTTP over loopback

The reproduction contains SDK clients, an SDK MCP server, and a minimal local OAuth provider. It has no Netclaw dependencies.

git clone https://github.com/Aaronontheweb/mcp-anonymous-oauth-spike.git
cd mcp-anonymous-oauth-spike
git checkout 55cc2c9
./verify.sh

The script verifies the original behavior and the workaround described below. It returns zero only when the observed behavior and expected failure match their assertions.

Observed behavior

Server behavior	After initialization and tool discovery	After a protected tool call
Challenges initialization	OAuth completes	Tool succeeds
Allows anonymous discovery	No OAuth callback or token exchange	HTTP 401 triggers OAuth; tool succeeds

Normal authorization after an HTTP challenge works. The missing capability concerns explicit authorization before tool use.

Workaround tested

We supplied an HttpClient with a custom DelegatingHandler. After a metadata preflight, it returns one synthetic HTTP 401 for the candidate's first unauthenticated MCP POST.

The SDK then performs discovery, authorization, PKCE, and token exchange. Its authenticated retry reaches the actual MCP server.

This completes authorization before any tool executes, without reflection or an SDK fork.

The negative tests also show that SDK initialization can succeed anonymously after a rejected token exchange. The host must check the candidate token cache separately.

Workaround implementation · Recorded results

Requested capability

Is there a supported public API for this use case?

If not, would you consider an explicit authorization operation that:

• Uses the existing SDK OAuth implementation and callback.
• Acquires credentials without invoking a server tool.
• Supports cancellation and reports authorization failure distinctly from MCP connection success.
• Supports explicit reauthorization without first deleting active credentials.

The synthetic challenge demonstrates a possible workaround. A supported API would let hosts avoid dependence on the current HTTP challenge and retry sequence.

This reproduction does not establish a protocol violation or test Google's exact protected-operation responses.

Start with the standalone reproduction at revision 55cc2c9 and run verify.sh to confirm the anonymous initialization and synthetic-challenge behavior. Read ExplicitAuthorizationHandler.cs alongside the SDK's AuthorizationCallbackHandler flow, then define what a public authorization operation must report for success, cancellation, failure, and reauthorization without invoking a tool.