Support multiple remote toolsets via URL for managed MCP clients without custom headers

Inizia tracciando il routing degli URL del server remoto ospitato per /mcp/x/{toolset}, /readonly e /x/all, quindi confrontalo con la validazione e la normalizzazione esistenti di X-MCP-Toolsets. Definisci e documenta una forma URL-safe per più toolset, inclusa la precedenza quando sono presenti anche gli header. Il lavoro è completato quando i client gestiti possono selezionare un bundle limitato e validato senza usare /x/all.

Describe the feature or problem you’d like to solve

The hosted GitHub MCP server currently supports a single toolset by URL (/mcp/x/{toolset}) and multiple toolsets through the X-MCP-Toolsets request header.

That leaves managed MCP clients that expose the server endpoint and OAuth configuration but do not allow arbitrary per-request HTTP headers unable to select a bounded combination of toolsets. One concrete example is a ChatGPT custom/developer MCP app: its current app configuration flow exposes endpoint/metadata/authentication and tool scanning, but not an arbitrary X-MCP-Toolsets header field.

The practical choices are therefore currently:

1. remain on the default toolset and lose useful optional capabilities;
2. create several separate MCP app connections, one per /x/{toolset} URL; or
3. use /x/all, which exposes substantially more tools than needed and works against least-privilege/tool-surface minimization.

My concrete desired bundle is:

default,actions,projects,git,notifications,governance

The use case is an interactive GitHub MCP connection that needs ordinary repository/issue/PR operations plus CI inspection/control, Projects, repository tree access, notifications, and governance, while intentionally not exposing unrelated toolsets.

Proposed solution

Add a URL-addressable way to select multiple toolsets on the hosted remote server, while preserving the existing header behavior. For example, one of:

• /mcp/x/default,actions,projects,git,notifications,governance
• /mcp?toolsets=default,actions,projects,git,notifications,governance
• another documented, URL-safe equivalent.

Requirements I would suggest:

• use the same validation/normalization as X-MCP-Toolsets;
• support the default pseudo-toolset plus additional toolsets;
• reject unknown toolsets rather than silently broadening access;
• remain composable with /readonly and existing URL-addressable modes where applicable;
• keep headers authoritative when both mechanisms are present, or document an unambiguous precedence rule;
• do not make /x/all the required workaround for managed clients.

Example prompts or workflows

A managed ChatGPT MCP app could point to one stable endpoint representing exactly the approved bundle, then scan tools normally. The same pattern would help other hosted/managed MCP clients that cannot inject custom headers.

Why this matters

GitHub already recommends selecting only the toolsets needed because tool-surface size affects model tool selection and security. URL-addressable multi-toolset selection lets managed clients follow that recommendation instead of choosing between missing capabilities, duplicated app connections, or all.

This request is separate from #3231 / PR #3232, which address patch-safe large-file updates.