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

まず、ホストされたリモートサーバーの /mcp/x/{toolset}、/readonly、/x/all に対する URL ルーティングを追跡し、既存の X-MCP-Toolsets の検証および正規化と比較します。複数の toolset に対応する URL-safe な形式を 1 つ定義して文書化し、ヘッダーも存在する場合の優先順位を含めます。managed client が /x/all を使わずに、範囲が限定され検証済みの bundle を選択できれば完了です。

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.