Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Version-Based Tool Registration for MCP Server

Aperta
  • Qualcosa non va?
#1,216 1 commento 10 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 2 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Tranquilla
Stack tecnologico
csharp
Ambito
api, backend-api-design

Direzione di ricerca

Inizia leggendo le API esistenti WithTools() e quelle per la registrazione degli strumenti a livello di assembly, quindi esamina MapMcp e le relative opzioni di trasporto HTTP. L’issue propone il rilevamento basato sui namespace e vincoli sugli endpoint consapevoli della versione, ma la forma dell’API supportata e l’ambito dell’implementazione devono ancora essere definiti; il lavoro sarà completo quando sarà concordato un design che consenta la registrazione selettiva e versionata degli strumenti senza duplicare la configurazione del server.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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
Lingua principale
C#
Stelle
4.5k
Fork
814
Merge medio
9g 19h
PR unite (30g)
4

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di modelcontextprotocol/csharp-sdk

Tutte le issue di modelcontextprotocol/csharp-sdk

Issue simili

Altre issue su C#

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.