Thanks for updating your PR! It now meets our contributing guidelines. 👍

Hey @Sanjay-doppalapudi — nice work on this, we hit the exact same issue with Google's MCP servers and independently filed #26912 to fix it.

Our PRs overlap on the core problem: connect() succeeds without auth, so the SDK never triggers OAuth. Your forced auth() call in startAuth() addresses that well.

However, there's a second problem that affects Google specifically: after forcing auth(), the SDK calls discoverOAuthMetadata() which does a GET /.well-known/oauth-authorization-server against the MCP server URL (e.g. googleapis.com). Google doesn't implement RFC 8414 discovery, so that fetch fails and the OAuth flow still doesn't complete.

Our PR (#26912) addresses both:

1. The same auth-trigger fix (forcing auth() when no tokens exist)
2. A discoveryState() / saveDiscoveryState() implementation on McpOAuthProvider that lets users specify authorizationEndpoint and tokenEndpoint in config — the SDK checks discoveryState() before attempting .well-known discovery, so it skips the failing fetch entirely

Happy to collaborate on this — we could merge the approaches, or I could rebase our discovery piece on top of yours if the maintainers prefer that structure. Let me know what makes sense.

Hey @yanniznik,
Good catch on the RFC 8414 discovery issue ,I hadn't hit that in testing since the Google Drive server I was working with was failing earlier in the flow.
Your approach of implementing discoveryState() / saveDiscoveryState() on McpOAuthProvider with configurable authorizationEndpoint and tokenEndpoint seems like the right way to handle servers that don't support .well-known discovery. The SDK checks discoveryState() first, so if we save the endpoints there, it skips the failing fetch.
I think the cleanest path is:

1. Merge this PR (fix: force OAuth flow when server accepts unauthenticated connections #26236) - it handles the core fix (forcing the OAuth trigger when the server silently accepts unauthenticated connections)
2. You rebase your discovery piece on top of it - that way you get the forced auth() call for free and just need the discoveryState/config plumbing
   The two changes touch different parts of the codebase (mine is in startAuth/authenticate, yours is in the McpOAuthProvider and config schema), so they compose cleanly without conflicts.
   If the maintainers prefer a single combined PR instead, I'm happy to either pull your discovery changes into this one or close mine in favor of yours. Whatever's easiest for review.