Repository navigation
Inspector adds invalid trailing slash if resource is pathless URL #927
Description
Inspector Version
- v0.17.2
Describe the bug
If the oauth-protected-resource is a URL without a path, then MCP Inspector adds a trailing slash to the resource name when constructing the Authorization URL. This breaks logging in e.g. in Microsoft Entra because the resource name no longer matches the (slash-less) application URI.
To Reproduce
Steps to reproduce the behavior:
- Start an MCP server with a resource like this at e.g. https://localhost:7026/.well-known/oauth-protected-resource:
{
"resource": "https://localhost:7026",
"authorization_servers": [
"https://summerdawnaiexternal.ciamlogin.com/summerdawnaiexternal.onmicrosoft.com/v2.0"
],
"scopes_supported": [
"https://localhost:7026/connect"
],
"bearer_methods_supported": [
"header"
]
}-
Go through the Guided OAuth Flow in MCP Inspector until Preparing Authorization
-
Note that the constructed URL lists the resource with a trailing slash, e.g.
https://summerdawnaiexternal.ciamlogin.com/897a8a6d-b7f2-4790-91cd-d596869474a7/oauth2/v2.0/authorize?response_type=code&client_id=...&code_challenge=...&code_challenge_method=S256&redirect_uri=http://localhost:6274/oauth/callback/debug&state=...&scope=https://localhost:7026/connect&resource=https://localhost:7026/
If the URL is opened, it results in an error "AADSTS9010010: The resource parameter provided in the request doesn't match with the requested scopes." If the trailing slash is removed, the login succeeds.
Expected behavior
The resource in the Authorization URL should exactly match the resource in the oauth-protected-resource.
Environment (please complete the following information):
- OS: Windows 11
- Browser Chrome
Activity
cliffhall commentedon Aug 1, 2026
Closing: v1 is deprecated.
Thank you for reporting this, and apologies for the long wait for a response.
v1 will receive security fixes only — this issue describes a functionality, compatibility, or usability problem rather than a vulnerability, so it is being closed against v1. This is not a judgment on whether the problem is real — it's a consequence of the v1 line being frozen. This is happening as part of #1872.
If this still happens in v2, we'd genuinely like to know. v2 is a complete rewrite — three clients over a shared core — so many v1 behaviours no longer exist in the same form. Please open a fresh issue against v2 with steps to reproduce, and we'll look at it. Note that we accept external contributions as issues rather than pull requests; maintainers handle design and implementation through a prompt-driven workflow. See
CONTRIBUTING.md.Thanks for taking the time to report it.