/.well-known/oauth-protected-resource: protected-resource discovery

The first document a client reads. It answers one question: which authorization server guards this resource?

https://example.com/.well-known/oauth-protected-resource

GET, public, returns JSON.

What it contains

Two fields:

The resource is the canonical MCP URL, and the issuer is the site's own root URL without a trailing slash. Both are derived from the site's home URL.

How a client reaches it

It is not configured anywhere. The client calls the MCP endpoint without credentials, receives 401, and reads the WWW-Authenticate header, which names this URL. It then follows the pointer.

That is why a client only ever needs the MCP URL. See How discovery works.

Why the resource value matters

The resource here is the same value the client must send as the resource parameter during authorization and token exchange. The server compares scheme, host, port and path exactly, and rejects a mismatch with invalid_resource.

So this document is also the authoritative statement of the URL to configure. If a client fails at the token step, compare its configured server URL against the resource here character by character — a www difference or a trailing path segment is enough to fail.

Clients that omit the resource parameter are accepted, since some MCP clients do not send it.

It is a rewrite rule

The .well-known paths are served through WordPress rewrite rules, not real files. Two consequences:

• Pretty permalinks are required. With plain permalinks this URL returns your site's 404 page while the MCP endpoint still works — a confusing combination that stops discovery dead.
• A physical .well-known directory can shadow it. If the web server serves a real file at that path, WordPress never sees the request. Some TLS providers create one; check if discovery fails on a site with correct permalinks.

Multilingual sites

When POM Translate prefixes URLs with a language code, the server also answers the localized form — /es/.well-known/oauth-protected-resource — while continuing to advertise the canonical unprefixed URL.

This exists so a redirect through a translated URL does not break the flow. Configure clients with the canonical form.

Caching and CORS

The response is sent with no-store cache headers and a JSON content type. Cross-origin requests are answered only for origins on your allowlist; OPTIONS preflight returns 204.

Exclude the path from CDN caching. A cached copy from before a domain change will point clients at the wrong resource.

Checking it

Open it in a browser. You should see a small JSON object naming your MCP endpoint and your site.

That last case is worth checking on sites reachable at both example.com and www.example.com: the document reports whichever WordPress considers canonical, and that is the one clients must use.

The diagnostics in the MCP settings panel fetch this document from the server itself and report the status, content type and whether it parsed as JSON.

Next

Authorization server metadata, the document this one points to.