Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Version-Based Tool Registration for MCP Server

Abierto
  • ¿Algo no está bien?
#1,216 1 comentario 10 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Tranquilo
Stack tecnológico
csharp
Área
api, backend-api-design

Línea de trabajo

Comienza leyendo las API existentes WithTools() y de registro de herramientas para todo el assembly; después, inspecciona MapMcp y sus opciones de transporte HTTP. El issue propone un descubrimiento basado en namespaces y restricciones de endpoint conscientes de la versión, pero aún hay que decidir la forma de API compatible y el alcance de la implementación; se considerará terminado cuando exista un diseño acordado que permita un registro selectivo y versionado de herramientas sin duplicar la configuración del servidor.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

enhancement P3 ready for work

Is your feature request related to a problem? Please describe.
When building MCP servers in .NET, especially HTTP-based servers with versioned endpoints, there is currently no first-class support for tool versioning and selective tool registration.
All tools are typically registered globally (e.g. via WithTools() or assembly-wide scanning), which makes it difficult to:

  • Expose multiple API versions (/v1, /v2, …) in parallel
  • Maintain backward compatibility while evolving tools
  • Avoid duplicating MCP server registrations per version
  • Keep tool discovery explicit and predictable in larger codebases

This becomes especially painful in real-world services where:

  • Tools are organized by namespace (e.g. MyNamespace.Mcp.v1, MyNamespace.Mcp.v2)
  • Different MCP endpoints should only expose a subset of tools
  • Versioning logic must be reimplemented manually outside the SDK

Describe the solution you'd like
I propose adding official support for namespace- and version-based tool registration, enabling clean MCP API versioning.

  1. Namespace-based tool discovery helper
    A built-in extension similar to the following:
public static class McpVersioningExtensions
{
    public static IMcpServerBuilder WithToolsFromNamespaces(
        this IMcpServerBuilder builder,
        Assembly assembly,
        params string[] namespaceNames)
    {
        IEnumerable<Type> toolTypes =
            from t in assembly.GetTypes()
            where t.GetCustomAttribute<McpServerToolTypeAttribute>() is not null
            where t.Namespace != null
               && namespaceNames.Any(ns =>
                   t.Namespace.StartsWith(ns, StringComparison.Ordinal))
            select t;

        return builder.WithTools(toolTypes);
    }
}

Usage:

builder.Services.AddMcpServer(options =>
{
    options.ServerInfo.Version = "1.0.0";
})
.WithHttpTransport()
.WithToolsFromNamespaces(
    typeof(Program).Assembly,
    "MyNamespace.Mcp.v1");

This allows:

  • Clear separation of tools by namespace
  • Explicit control over which tools belong to which API version
  • No reflection boilerplate in application code
  1. Version-aware endpoint mapping
    Combine tool versioning with HTTP endpoint constraints:
app.MapMcp("/v1", options =>
{
    options.RequiredServerVersion = "1.0.0";
});

app.MapMcp("/v2", options =>
{
    options.RequiredServerVersion = "2.0.0";
});

This enables:

  • Parallel MCP versions in the same service
  • Clean routing and contract enforcement
  • Safe evolution of tools without breaking clients

Describe alternatives you've considered

  • Multiple MCP servers per version
    → Leads to duplicated configuration, duplicated transports, and higher maintenance cost.
  • Manual reflection and filtering outside the SDK
    → Works, but reimplements logic that many users will need and reduces consistency across projects.
  • Tool-level version attributes only
    → Still requires custom registration logic and does not integrate naturally with HTTP endpoint versioning.

Additional context
This feature would be particularly valuable for:

  • Enterprise services with long-lived clients
  • Public MCP endpoints with semantic versioning
  • Teams migrating from REST/gRPC APIs to MCP while preserving version contracts

Providing an official abstraction for namespace- or version-based tool registration would:

  • Reduce boilerplate
  • Encourage best practices
  • Make the SDK significantly more production-ready for real-world API versioning scenarios
Lenguaje dominante
C#
Estrellas
4.6k
Forks
817
Merge medio
8 d 7 h
PR fusionados (30 d)
3

Preparar el entorno

Abrir en Codespaces

Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de modelcontextprotocol/csharp-sdk

Todos los issues de modelcontextprotocol/csharp-sdk

Issues similares

Más issues de C#

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.