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.

从 MCP server 的 well-known 路由配置入手，检查 EXTERNAL 模式如何公开 /.well-known/oauth-authorization-server。将其行为与链接的 MCP authorization specification 进行比较，并验证 WWW-Authenticate 流程。完成的标准是 MCP server 公开 /.well-known/oauth-protected-resource，其中包含外部 authorization server 的 URL，并且不再公开 authorization server 元数据端点。