Trailing slash in OAuthMetadata's `issuer` causes issues with clients

Beginne beim OAuthMetadata-Modell und dem Endpunkt .well-known/oauth-authorization-server und untersuche anschließend, wie Pydantics AnyHttpUrl den issuer-Wert normalisiert. Prüfe die Anforderungen von RFC 8414 und die bestehende Issue-Diskussion, bevor du entscheidest, wie ein einzelner abschließender Schrägstrich behandelt werden soll; abgeschlossen ist die Aufgabe, wenn der zurückgegebene issuer und die Discovery-URL mit den betroffenen Clients kompatibel bleiben.

Initial Checks

• I confirm that I'm using the latest version of MCP Python SDK
• I confirm that I searched for my issue in https://github.com/modelcontextprotocol/python-sdk/issues before opening this issue

Description

In the .well-known/oauth-authorization-server endpoint and , the issuer is forced to always contain a trailing slash e.g.,

• https://your-mcp.com/ instead of
• https://your-mcp.com
  as a byproduct of using pydantic's AnyHttpUrl type.

This causes issues in both Google's ADK and IBM's MCP Context Forge because:

• when building the .well-known URL, they expect a discovery issuer URL that does not contain a trailing slash; and
• then they MUST verify that the returned metadata issuer URL is identical to the discovery issuer URL ("authorization server's issuer identifier value" in the spec) according to RFC 8414 Section 3.2; so
• when OAuthMetadata.issuer contains the trailing slash, the discovery process is aborted.

OAuth 2.0 Authorization Server Metadata spec says that the client MUST remove trailing paths from when the issuer contains a path component:

If the issuer identifier value contains a path component, any
terminating "/" MUST be removed before inserting "/.well-known/" and
the well-known URI suffix between the host component and the path
component.
-- https://datatracker.ietf.org/doc/html/rfc8414#section-3.1

if the trailing / in https://example.com/ is a "path component", and should thus be stripped by the client, so I think the spec is ambiguous about the responsibilities of the client in the case where there the issuer identifier value contains a lone trailing slash.

I did note that the examples of issuer identifiers in the spec do not contain a lone trailing slash, i.e. they are https://example.com rather than https://example.com/.

For these reasons, and

• while it's listed as the client's responsibility to remove trailing slashes from the issuer identifier,
• I don't believe it's the server implementation's responsibility to intentionally make it harder for clients by returning a URL that do not follow the assumptions in the spec.

I think it's worth it to consider interpreting the spec as "the issuer field should not contain a trailing slash".

I also believe this issue could be similar in mechanism, but different in scope, to what is described in https://github.com/modelcontextprotocol/python-sdk/issues/1265

Example Code

# A demonstration on how AnyHttpUrl adds a trailing slash.

>>> from pydantic.networks import AnyHttpUrl
>>> x = AnyHttpUrl("http://localhost:8000")
>>> x
AnyHttpUrl('http://localhost:8000/')
>>> str(x)
'http://localhost:8000/'
>>>

Python & MCP Python SDK

Python 3.14
mcp==1.25.0