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

首先跟踪托管远程服务器针对 /mcp/x/{toolset}、/readonly 和 /x/all 的 URL 路由，然后将其与现有的 X-MCP-Toolsets 验证和规范化进行比较。定义并记录一种 URL-safe 的多 toolset 形式，包括同时存在 header 时的优先级。完成标准是：受管理的客户端可以选择一个范围受限且经过验证的 bundle，而无需使用 /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.