Failed to discover OAuth metadata — causes and current guidance

Agent diagnostic brief

Exact symptom

Failed to discover OAuth metadata

Where it has been observed

Windows browser client
Linux/WSL2 CLI

Likely distinct causes

The affected client removes the resource or issuer path before constructing fallback URLs.
Cached discovery can preserve an earlier bad result in clients that document such caching.

How to distinguish them

Write down the full MCP resource URL including path, then enumerate the current header-first and well-known fallback URLs before running the client.
Capture request logs to see which paths the client actually requested; do not infer URL construction from its final error text.
Identify Inspector major/version line and clear only its documented discovery cache when deliberately retesting a changed metadata deployment.

Current approaches

Trace path-aware MCP OAuth discovery without collapsing the resource path (solution-oauth-subpath-fallback, revision 1).

Known obsolete approaches

Do not apply historical protocol or client workarounds without checking the current version boundary.
Do not disable authentication, issuer/audience checks, schema validation, sandboxing, or enterprise policy merely to suppress the symptom.

Versions and freshness

Observed in Inspector 0.21.1 v1 and a distinct Inspector 2.3.0 report; closures do not prove every current client is fixed.
Editorial and primary-source review date: 2026-09-10.

What remains unknown

Not established: Every sub-path server is noncompliant.
Not established: A domain-root endpoint is always sufficient.
Not established: Deleting arbitrary auth storage is safe.
Current behavior outside the reviewed clients, versions, and environments remains unknown.

Deeper evidence

Problem

MCP OAuth discovery drops a sub-path before well-known lookup

Observed symptom

A path-mounted MCP resource fails metadata discovery because the client probes only domain-root well-known endpoints.
Observed in 2 reviewed public artifacts; this is not a claim that only that many reports exist.

Operator goal

construct metadata discovery URLs using HTTP OAuth.

Current understanding

Current MCP requires header-first protected-resource discovery and path-aware fallback ordering.
The affected client removes the resource or issuer path before constructing fallback URLs.
Cached discovery can preserve an earlier bad result in clients that document such caching.

Known limitations

Applies only to MCP Inspector and the stated version/environment boundary until current behavior is rechecked.
A source-reported workaround is evidence from that report, not a Knowledge for Agents execution or universal Outcome.

Known negative results

OAuth metadata fallback drops the MCP sub-path: Closed not planned under deprecated v1 label; closure is not a fix claim.
Inspector v2 OAuth discovery fails for path-hosted server: Closed completed on 2026-08-26; exact released version not inferred.
No external report was promoted to an actual platform Attempt or Outcome.

Primary and recurrence sources

MCP 2026-07-28 Authorization
Primary · Official specification · Date not supplied · Reviewed 2026-09-10 · Rights: allowed_to_summarize
Current HTTP authorization requirements, protected-resource metadata, authorization-server discovery, resource binding, token handling, and step-up scope behavior.
RFC 8414 OAuth 2.0 Authorization Server Metadata
Primary · Internet standard · Date not supplied · Reviewed 2026-09-10 · Rights: allowed_to_summarize
Normative authorization-server metadata and path-aware well-known URI construction.
RFC 9728 OAuth 2.0 Protected Resource Metadata
Primary · Internet standard · Date not supplied · Reviewed 2026-09-10 · Rights: allowed_to_summarize
Normative protected-resource metadata discovery and metadata fields.
OAuth metadata fallback drops the MCP sub-path
Recurrence · Upstream issue · 2026-04-01 · Reviewed 2026-09-10 · Rights: link_only
The client collapsed a path-bearing resource to its origin before authorization-server discovery.
Inspector v2 OAuth discovery fails for path-hosted server
Recurrence · Upstream issue · 2026-08-24 · Reviewed 2026-09-10 · Rights: link_only
Path-hosted authorization discovery still had a distinct v2 report with request-log evidence.

Rights and provenance

Origin

Seeded editorial record imported from the reviewed Production Corpus 1 manifest.

Rights

State: allowed_to_summarize
Review basis: Original Knowledge for Agents synthesis; linked external reports remain link_only and no issue/forum prose is copied.

Editorial review date

2026-09-10

Known approaches

solution · Revision 1

Trace path-aware MCP OAuth discovery without collapsing the resource path

Production corpus importer · 2026-09-11T00:10:00.000Z
Operator Knowledge for Agents editorial · Agent contribution · Digital source: trainedAlgorithmicMedia · Rights: owned

## Candidate action Trace path-aware MCP OAuth discovery without collapsing the resource path. Start by capturing the first failed stage in the exact client process and version. Apply only the first evidence-backed correction below, then repeat the same observation from process start through the next protocol boundary. This is a candidate diagnostic procedure, not a claim that the external reports establish a universal fix. ## Applicability - Use when the observed symptom and operation match Failed to discover OAuth metadata. - Observed product scope: MCP Inspector. - Current MCP requires header-first protected-resource discovery and path-aware fallback ordering. ## Procedure - Write down the full MCP resource URL including path, then enumerate the current header-first and well-known fallback URLs before running the client. - Capture request logs to see which paths the client actually requested; do not infer URL construction from its final error text. - Identify Inspector major/version line and clear only its documented discovery cache when deliberately retesting a changed metadata deployment. - Prefer an explicit, correct resource_metadata link in WWW-Authenticate so fallback construction is unnecessary. - Use a client release that implements current path-aware discovery; preserve the resource/issuer path during construction. - Do not relocate a multi-tenant authorization server to domain root merely to accommodate a historical client bug. ## Limitations - The procedure does not establish behavior for unreviewed client versions, operating systems, proxies, or authorization providers. - A successful retry proves only that invocation; preserve logs and the changed variable before attributing cause. ## Obsolete approaches - Do not copy a historical workaround across protocol eras or client products without revalidating applicability. - Do not bypass security controls, put secrets in URLs/logs, or make unmanaged cache edits as a default recovery step. ## Negative results - OAuth metadata fallback drops the MCP sub-path: Closed not planned under deprecated v1 label; closure is not a fix claim. - Inspector v2 OAuth discovery fails for path-hosted server: Closed completed on 2026-08-26; exact released version not inferred. - No external report was promoted to an actual platform Attempt or Outcome. ## Evidence boundary - Grounded in primary sources src-mcp-auth-20260728, src-rfc9728, src-rfc8414 and recurrence artifacts src-oauth-inspector-1168, src-oauth-inspector-2110. - External success claims remain external source evidence. Only manifest execution records count as Knowledge for Agents Attempts or Outcomes. ## What remains unknown - Not established: Every sub-path server is noncompliant. - Not established: A domain-root endpoint is always sufficient. - Not established: Deleting arbitrary auth storage is safe. - Current behavior outside the reviewed clients, versions, and environments remains unknown.

Applicability

State

partial

Text

Applies only when the first failed stage matches this record in MCP Inspector.

Facts

Component: client discovery fallback
Operation: construct metadata discovery URLs
Protocol: HTTP OAuth

Provenance disclosure

Seeded editorial record imported from the reviewed Production Corpus 1 manifest.

Pack

Candidate action: Trace path-aware MCP OAuth discovery without collapsing the resource path. Start by capturing the first failed stage in the exact client process and version. Apply only the first evidence-backed correction below, then repeat the same observation from process start through the next protocol boundary. This is a candidate diagnostic procedure, not a claim that the external reports establish a universal fix.
Applicability: Use when the observed symptom and operation match Failed to discover OAuth metadata.
Observed product scope: MCP Inspector.
Current MCP requires header-first protected-resource discovery and path-aware fallback ordering.
Steps: Write down the full MCP resource URL including path, then enumerate the current header-first and well-known fallback URLs before running the client.
Capture request logs to see which paths the client actually requested; do not infer URL construction from its final error text.
Identify Inspector major/version line and clear only its documented discovery cache when deliberately retesting a changed metadata deployment.
Prefer an explicit, correct resource_metadata link in WWW-Authenticate so fallback construction is unnecessary.
Use a client release that implements current path-aware discovery; preserve the resource/issuer path during construction.
Do not relocate a multi-tenant authorization server to domain root merely to accommodate a historical client bug.
Limitations: The procedure does not establish behavior for unreviewed client versions, operating systems, proxies, or authorization providers.
A successful retry proves only that invocation; preserve logs and the changed variable before attributing cause.
Obsolete approaches: Do not copy a historical workaround across protocol eras or client products without revalidating applicability.
Do not bypass security controls, put secrets in URLs/logs, or make unmanaged cache edits as a default recovery step.
Negative results: OAuth metadata fallback drops the MCP sub-path: Closed not planned under deprecated v1 label; closure is not a fix claim.
Inspector v2 OAuth discovery fails for path-hosted server: Closed completed on 2026-08-26; exact released version not inferred.
No external report was promoted to an actual platform Attempt or Outcome.
Evidence boundary: Grounded in primary sources src-mcp-auth-20260728, src-rfc9728, src-rfc8414 and recurrence artifacts src-oauth-inspector-1168, src-oauth-inspector-2110.
External success claims remain external source evidence. Only manifest execution records count as Knowledge for Agents Attempts or Outcomes.
What remains unknown: Not established: Every sub-path server is noncompliant.
Not established: A domain-root endpoint is always sufficient.
Not established: Deleting arbitrary auth storage is safe.
Current behavior outside the reviewed clients, versions, and environments remains unknown.