Remote MCP server, well known protected endpoint missing

[Nick Koukounakis]

Hey we are building an MCP client.

According to the mcp spec
MCP servers MUST implement one of the following discovery mechanisms to provide authorization server location information to MCP clients:

1. WWW-Authenticate Header: Include the resource metadata URL in the WWW-Authenticate HTTP header under resource_metadata when returning 401 Unauthorized responses, as described in RFC9728 Section 5.1.
2. Well-Known URI: Serve metadata at a well-known URI as specified in RFC9728. This can be either:
   • At the path of the server’s MCP endpoint: https://example.com/public/mcp could host metadata at https://example.com/.well-known/oauth-protected-resource/public/mcp
   • At the root: https://example.com/.well-known/oauth-protected-resource

We tried the discovery mechanism but nothing worked in your mcp server. 
Is this something that is not supported yet on your mcp server? 

```

curl -i https://mcp.atlassian.com/v1/mcp
HTTP/2 401
date: Wed, 28 Jan 2026 13:25:02 GMT
content-type: application/json
content-length: 79
cf-ray: 9c50d040ac62dbe2-FRA
www-authenticate: Bearer realm="OAuth", error="invalid_token", error_description="Missing or invalid access token"
server: AtlassianEdge
ge-edge-trusted-cloudflare-proxy: bWNwLWNsb3VkZmxhcmUK
x-content-type-options: nosniff
x-xss-protection: 1; mode=block
atl-traceid: 50af456a5ad64df6a3006acfadbcdfa0
atl-request-id: 50af456a-5ad6-4df6-a300-6acfadbcdfa0
strict-transport-security: max-age=63072000; preload
report-to: {"endpoints": [{"url": "https://dz8aopenkvv6s.cloudfront.net"}], "group": "endpoint-1", "include_subdomains": true, "max_age": 600}
nel: {"failure_fraction": 0.01, "include_subdomains": true, "max_age": 600, "report_to": "endpoint-1"}
server-timing: atl-edge;dur=21,atl-edge-internal;dur=2,atl-edge-upstream;dur=19,atl-edge-pop;desc="aws-eu-central-1"

{"error":"invalid_token","error_description":"Missing or invalid access token"}%
```

Both
* https://mcp.atlassian.com/.well-known/oauth-protected-resource and
* https://mcp.atlassian.com/.well-known/oauth-protected-resource/v1/mcp
returns 404

So the MCP server does NOT fully conform to the MCP authorization specification. It lacks the required OAuth 2.0 Protected Resource Metadata (RFC 9728) implementation. While it provides the Authorization Server Metadata, at https://mcp.atlassian.com/.well-known/oauth-authorization-server.

Clients cannot use the spec-compliant discovery. 

[Dr Valeri Colon _Connect Centric_ · Accepted solution]

Welcome to the community @Nick Koukounakis You’re correct: Atlassian’s remote MCP server does not yet implement the OAuth 2.0 Protected Resource Metadata endpoints required by RFC 9728, and it does not expose resource_metadata in the WWW-Authenticate header. Only the authorization-server metadata endpoint is live. This means spec-compliant discovery isn’t currently possible, and MCP clients must rely on the documented fixed endpoints and OAuth 2.1 flow. Atlassian has acknowledged this gap, but no timeline has been published for full RFC 9728 compliance.

[Nick Koukounakis]

Thanks for confirming! We'll implement a workaround for now, no problem.