Option to support declarative tool registration activated by version (e.g. "beta")

Is your feature request related to a problem? Please describe.

Currently, there is no clear way to adding new endpoints under test and keeping those from the broader user audience.

This makes incremental rollouts of new tools challenging because it is not possible to easily have some users opt in progressively to receive new features for stability testing.

Describe the solution you'd like

• When tools are registered, allow it to be registered with a version
• Spitballing:
  • Version specification: accept route match (*/vnext/*) or header (x-mcp-version: vnext)
  • Example: [McpServerTool(Name = "my_tool", VersionHeader = "x-mcp-version", VersionMatch = "vnext")]
• This sets up the filter in the middleware automatically and checks incoming headers against the toolset metadata, automatically removing ones that target specific versions; effectively, it says client must transmit the header to see this tool.

Describe alternatives you've considered

Current workaround is to directly manipulate the ToolCollection dynamically:

server.WithListToolsHandler(
    async (context, cancellationToken) =>
    {
        // Resolve HttpContext via DI
        var httpContext = context
            .Services?.GetRequiredService<IHttpContextAccessor>()
            .HttpContext;

        // Check for the specific header
        bool betaEnabled =
            httpContext?.Request.Headers.ContainsKey("x-biblio-enable-beta") ?? false;

        if (!betaEnabled)
        {
            var betaTools =
                context.Server?.ServerOptions?.ToolCollection?.Where(tool =>
                    tool.ProtocolTool.Title?.Contains("(BETA)") ?? false
                )
                ?? [];

            foreach (var tool in betaTools.ToList())
            {
                // 👇 Active removal
                context?.Server?.ServerOptions?.ToolCollection?.Remove(tool);
            }
        }

        return new ListToolsResult
        {
            Tools = [], // Empty; these are additional tools.
        };
    }
);

Additional context

Similar to these issues:

• https://github.com/modelcontextprotocol/csharp-sdk/issues/1216
• https://github.com/modelcontextprotocol/csharp-sdk/issues/612

Start by tracing declarative tool registration, the tool metadata represented by McpServerTool, and the middleware or list-tools path that currently exposes ToolCollection. Define how route or header version matching should be represented and filtered, then verify that versioned tools remain hidden unless the matching client request is present without breaking normal tool discovery.