Confusion with `WWW-Authenticate` and EXTERNAL server mode

Inizia dalla configurazione delle route well-known del MCP server e analizza come la modalità EXTERNAL espone /.well-known/oauth-authorization-server. Confronta il comportamento con la MCP authorization specification collegata e verifica il flusso WWW-Authenticate. Il lavoro è completato quando il MCP server espone /.well-known/oauth-protected-resource con l’URL dell’authorization server esterno e non espone più l’endpoint dei metadati dell’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.