Confusion with `WWW-Authenticate` and EXTERNAL server mode

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.

Start at the MCP server's well-known route configuration and inspect how EXTERNAL mode exposes /.well-known/oauth-authorization-server. Compare the behavior with the linked MCP authorization specification and verify the WWW-Authenticate flow. Done means the MCP server exposes /.well-known/oauth-protected-resource with the external authorization server URL and no longer exposes the authorization-server metadata endpoint.