Repository navigation
Too strict resource name validation 0.17.0 #855
Description
Inspector Version
- 0.17.0
Describe the bug
I'm getting error "Protected resource api://mycompany.com/subdivision/myservice does not match expected https://api.test.subdivison.mycompany.com/myservice/mcp (or origin)" My API is exposed via different endpoints (like Application Gateway, Azure API Management Service, from internal network Container App Environment Application Url...), which all have different domains. Official RFC https://datatracker.ietf.org/doc/html/rfc8707#name-resource-parameter is using a word MAY in sentence "The resource parameter URI value is an identifier representing the identity of the resource, which MAY be a locator that corresponds to a network-addressable location".
RFC also states "The parameter value identifies a resource to which the client is requesting access. The parameter can carry the location of a protected resource, typically as an https URL or a more abstract identifier."
To Reproduce
Steps to reproduce the behavior:
- npx @modelcontextprotocol/inspector
- open http://localhost:6274/?MCP_PROXY_AUTH_TOKEN=....
- Change Transport Type to Streamable HTTP
- Enter URL to https://api.test.subdivision.mycompany.com/myservice/mcp
- Click Open Auth Settings
- Click Guided OAuth Flow
- Click Continue
- Observe response from https://api.test.subdivision.mycompany.com/.well-known/oauth-protected-resource/myservice/mcp is returning
{
"resource": "api://mycompany.com/subdivision/myservice",
"authorization_servers": [
"https://identity-test.mycompany.com"
],
"bearer_methods_supported": [
"header"
],
"scopes_supported": [
"myservice"
]
} - ISSUE error is shown "Protected resource api://mycompany.com/subdivision/myservice does not match expected https://api.test.subdivision.mycompany.com/myservice/mcp (or origin)"
Expected behavior
Allow resource name to be any absolute URI.
Activity
kamranayub commentedon Dec 19, 2025
I don't think this is correct.
The corresponding spec is RFC 9728 for PRM, as
resourceis defined as:I think
resource_nameis what you're referring to:The
api://convention is what I've seen in scopes only (which is what I use with Entra ID).tomasr commentedon Feb 19, 2026
This is not correct, for sure.
Default Application ID's (i.e. resource values) in Entra ID use the
api://convention, and they work just fine if you're using the original OAuth authorization endpoint through theresourceparameter.Since it's the Application ID, it will be part of the
scopename if using thev2.0authorization endpoint which takes only thescopeparameter and does not accept theresourceparameter (and I don't think the MCP inspector will currently be able to use these).Regardless, why validate the resource identifier at all? The MCP server is telling you the resource identifier that should be used, so why validate that it exactly matches the MCP Server URL?
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.