Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

Version-Based Tool Registration for MCP Server

Offen
  • Stimmt etwas nicht?
#1,216 1 Kommentar 10 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 2 Tagen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
35/100
Issue-Typ
Feature
Klarheit
Muss geklärt werden
Aktivitätsstatus
Ruhig
Tech-Stack
csharp
Bereich
api, backend-api-design

Rechercherichtung

Beginne damit, die vorhandenen WithTools()- und assemblyweiten APIs zur Tool-Registrierung zu lesen, und untersuche anschließend MapMcp und dessen HTTP-Transportoptionen. Der Issue schlägt eine namensraumbasierte Erkennung und versionsabhängige Endpoint-Einschränkungen vor, aber die unterstützte API-Form und der Implementierungsumfang müssen noch festgelegt werden; als abgeschlossen gilt die Arbeit erst mit einem abgestimmten Design, das eine selektive, versionierte Tool-Registrierung ohne duplizierte Serverkonfiguration ermöglicht.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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
Vorherrschende Sprache
C#
Sterne
4.6k
Forks
852
Ø Merge
9 T. 3 Std.
Gemergte PRs (30 T.)
3

Entwicklungsumgebung

In Codespaces öffnen

Startet den Dev-Container des Projekts im Browser, mit Ihrem eigenen GitHub-Konto.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus modelcontextprotocol/csharp-sdk

Alle Issues in modelcontextprotocol/csharp-sdk

Ähnliche Issues

Weitere Issues zu C#

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.