Issue Station
Sign In
Tools hereToolbox

claude-code - 💡(How to fix) Fix [DOCS] Managed MCP URL-pattern docs omit `*://` scheme wildcard and hostname case matching for `deniedMcpServers` [1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#56499•Fetched 2026-05-06 06:26:25
View on GitHub
Comments
0
Participants
1
Timeline
3
Reactions
0
Author
coygeekcoygeek
Participants
coygeekcoygeek
Timeline (top)
labeled ×3

Code Example

{
"deniedMcpServers": [
{ "serverUrl": "*://*.untrusted.com/*" }
]
}
RAW_BUFFERClick to expand / collapse

Documentation Type

Incorrect/outdated documentation

Documentation Location

https://code.claude.com/docs/en/mcp

Section/Topic

Managed MCP configuration → Option 2: Policy-based control with allowlists and denylists → How URL-based restrictions work

Current Documentation

The docs currently say:

Each entry in the allowlist or denylist can restrict servers in three ways:

  1. By server name (serverName): Matches the configured name of the server
  2. By command (serverCommand): Matches the exact command and arguments used to start stdio servers
  3. By URL pattern (serverUrl): Matches remote server URLs with wildcard support

URL patterns support wildcards using * to match any sequence of characters. This is useful for allowing entire domains or subdomains.

Wildcard examples:

  • https://mcp.company.com/* - Allow all paths on a specific domain
  • https://*.example.com/* - Allow any subdomain of example.com
  • http://localhost:*/* - Allow any port on localhost

What's Wrong or Missing?

This section documents serverUrl wildcard matching in general, but it does not explain two important behaviors relevant to managed MCP deny/allow rules:

A. The *:// scheme wildcard is not documented

The v2.1.129 changelog notes a fix for deniedMcpServers patterns that use a *:// scheme wildcard. The managed MCP docs currently only show https://... and http://... examples, so admins are not told that one pattern can cover multiple schemes.

B. Hostname matching behavior is underspecified

The same v2.1.129 fix refers to mixed-case hostnames, but the docs do not state whether serverUrl hostname matching is case-sensitive or normalized. That leaves policy authors without clear guidance for writing deny rules that reliably match real-world URLs.

Suggested Improvement

Add explicit guidance under "How URL-based restrictions work," for example:

Add after the wildcard examples:

  • *://example.com/* - Match the same host on either HTTP or HTTPS
  • Hostname matching is case-insensitive, so https://EXAMPLE.com/mcp and https://example.com/mcp are treated the same for serverUrl matching

Also add one denylist example that uses the scheme wildcard, such as:

{
"deniedMcpServers": [
{ "serverUrl": "*://*.untrusted.com/*" }
]
}

Impact

Medium - Makes feature difficult to understand

Additional Context

Affected Pages:

PageLine(s)Context
https://code.claude.com/docs/en/mcp1295-1360serverUrl matching is described, but *:// and hostname case behavior are not documented

Total scope: 1 page affected

Relevant changelog context: v2.1.129 includes a fix for deniedMcpServers patterns using a *:// scheme wildcard that did not match mixed-case hostnames. That behavior should be reflected in the managed MCP configuration docs.

extent analysis

TL;DR

Update the documentation to include examples and explanations for the *:// scheme wildcard and hostname matching behavior in serverUrl patterns.

Guidance

  • Add an example to the documentation to demonstrate the use of the *:// scheme wildcard, such as *://example.com/*, to match the same host on either HTTP or HTTPS.
  • Clarify that hostname matching is case-insensitive, providing an example to illustrate this behavior, such as https://EXAMPLE.com/mcp and https://example.com/mcp being treated the same.
  • Include a denylist example that uses the scheme wildcard, such as the provided JSON snippet: ```json { "deniedMcpServers": [ { "serverUrl": "://.untrusted.com/*" } ] }
* Review the affected page (https://code.claude.com/docs/en/mcp, lines 1295-1360) to ensure the updated documentation accurately reflects the behavior of `serverUrl` matching.

## Notes
The suggested improvements should be added to the "How URL-based restrictions work" section, after the wildcard examples, to provide clear guidance for policy authors.

## Recommendation
Apply workaround: Update the documentation to include the suggested improvements, providing clear guidance on the use of the `*://` scheme wildcard and hostname matching behavior in `serverUrl` patterns.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#ssr#API middleware#SSR setup#ISR setup

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

claude-code - 💡(How to fix) Fix [DOCS] Managed MCP URL-pattern docs omit `*://` scheme wildcard and hostname case matching for `deniedMcpServers` [1 participants]