[FEATURE] Do not warn when a user-scope MCP server intentionally shadows a plugin's server at the same endpoint (or let the plugin opt out)

Problem Statement

When a plugin bundles an MCP server and the user also configures a user-scope server at the same URL on purpose (for example to supply the credential from a secret store or an environment variable, which the plugin's manifest cannot express), /plugin shows a warning for the plugin on every session:

MCP server "dometrain" skipped — same command/URL as already-configured "dometrain"
Remove "dometrain" from your MCP config if you want the plugin's version instead

The setup is intentional and works. The user-scope server is the one in use, and the plugin's server is meant to be replaced. The warning makes a supported configuration look broken, and the plugin author has no way to prevent it.

This is the same message reported in #39511 (claude.ai connectors with the same URL, closed as not planned after inactivity, now locked). That thread treated the message as informational. This request is about the case where the shadowing is deliberate and the documented setup for a plugin.

Proposed Solution

Any one of these would resolve it, in order of preference:

1. Do not surface a warning when the higher-precedence server that causes the skip is one the user configured themselves (local, project or user scope), since that is the documented precedence working as designed. Keep the warning for the case where the user probably did not know about the duplicate.
2. Add a manifest field on a plugin MCP server, for example yieldToUserScope: true, meaning "if a same-endpoint server exists at a higher scope, skip mine silently".
3. At minimum, document the message text and where it renders (Errors tab, /mcp, claude mcp list), so plugin authors can tell users what to expect.

Alternative Solutions

• Plugin authors can avoid the duplicate only by not shipping the server at all, which removes the zero-setup path for users who have no override.
• Renaming the plugin's server key does not help, because the docs say plugin servers are matched by endpoint, not by name (https://code.claude.com/docs/en/mcp, "Scope hierarchy and precedence").
• ${VAR:-default} cannot be used to make the plugin's own header fall back to an environment variable, because the docs define it for environment variables only and say nothing about ${user_config.*} inside it. So the plugin cannot conditionally omit its header either.
• Splitting the plugin into a skills-only plugin and a server-only plugin works but doubles the packaging for a display issue.

Priority

Low - Nice to have

Feature Category

MCP server integration

Use Case Example

1. A plugin ships a remote HTTP MCP server with an optional API key in userConfig.
2. A user keeps the key in a secret store, so they add a user-scope server at the same URL with a headersHelper and leave the plugin's key blank.
3. The user-scope server connects and works. /plugin still lists the plugin with the skipped-duplicate warning on every launch, and the user cannot clear it without removing their own working setup or the plugin.

Additional Context

• Claude Code 2.1.284 on Windows.
• The exact message text and where it renders are not on the plugins or MCP docs pages I checked. The MCP page describes the endpoint matching and precedence but does not list this warning.
• Related closed issues: #39511, #41193 (closed as a duplicate of it), #35573.