Confusion with `WWW-Authenticate` and EXTERNAL server mode

MCP server の well-known ルート設定から始め、EXTERNAL モードが /.well-known/oauth-authorization-server をどのように公開しているかを調査します。リンク先の MCP authorization specification と動作を比較し、WWW-Authenticate フローを確認します。MCP server が外部 authorization server の URL とともに /.well-known/oauth-protected-resource を公開し、authorization server のメタデータエンドポイントを公開しなくなれば完了です。

Describe the bug
It seems there is some confusion in this example project regarding the EXTERNAL mode.

In this mode, there should be two distinct servers:

• one for authentication (OAuth2),
• one for the MCP server.

However, even in EXTERNAL mode, the example project still exposes the resource /.well-known/oauth-authorization-server on the MCP server.
This should not be the case. This resource is exposed by the OAuth2 authorization server, not by the MCP server, no ?

According to the MCP specification, the MCP server should instead expose: /.well-known/oauth-protected-resource
(see: https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization#protected-resource-metadata-discovery-requirements)

This resource is discovered by the client via the WWW-Authenticate header, which contains the URL of the MCP protected-resource metadata.

The JSON returned by this /.well-known/oauth-protected-resource endpoint must provide the base URL of the external authorization server.
Example response:

{
  "resource": "http://localhost:3232/mcp",
  "resource_name": "MCP Server",
  "authorization_servers": [
    "http://localhost:3001"
  ]
}

The client then uses this information to discover the authorization server metadata, as described in the spec:
https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization#authorization-server-metadata-discovery

The spec allows several discovery patterns, such as:

• OAuth 2.0 Authorization Server Metadata with path insertion:
  https://auth.example.com/.well-known/oauth-authorization-server/tenant1

• OpenID Connect Discovery 1.0 with path insertion:
  https://auth.example.com/.well-known/openid-configuration/tenant1

• OpenID Connect Discovery 1.0 with path appending:
  https://auth.example.com/tenant1/.well-known/openid-configuration

This seems to be related to this topic on the inspector. Which seems to ignore the WWW-Authenticate header and make calls directly to the MCP server, expecting to deal with the authentication server.

To Reproduce

This issue can be observed by testing MCP clients + server that rely on this discovery mechanism.
For these clients, the current implementation does not work as expected.

Expected behavior

Add the /.well-known/oauth-protected-resource endpoint to the MCP server.
Remove the .well-known/oauth-authorization-server on the Mcp Server.Because it already displays this one by default.

Logs
If applicable, add logs to help explain your problem.

Additional context
Add any other context about the problem here.