Examples of adding tools dynamically based on methods from another class

[yashgoswami]

Pre-submission Checklist

• I have checked that this question would not be more appropriate as an issue in a specific repository
• I have searched existing discussions and documentation for answers

Question Category

• Protocol Specification
• SDK Usage
• Server Implementation
• General Implementation
• Documentation
• Other

Your Question

I have been following the SDK and examples and could create an MCP server based on a class (say MyMcpTools) having methods decorated with MCPServerTool attribute having description and names and then using .WithTools.

However, now I want to conditionally add tools from methods from a generic class which as injected Dependencies. And add tool description, name etc. dynamically (I will fetch them from config for example).

I tried using overloaded methods of McpServerTool.Create() but either it doesn't add McpServerToolCreateOptions to the tool or client not able to run the tool. Are there any clear examples that I can refer to achieve this.

[eng-marani]

You can add tool at runtime without any attribute decorated class, using this:

builder.WithTools(tools, serializerOptions);

tools list can be constructed by code, creating an array of McpServerTool

var tool = McpServerTool.Create(
    typeof(MyToolClass).GetMethod(nameof(MyToolClass.ToolInvoker))!);

tool.ProtocolTool.Name = ...
tool.ProtocolTool.Description = ...
tool.ProtocolTool.Title = ...
tool.ProtocolTool.InputSchema = CreateInputSchema(params);

tools.Add(tool);

CreateInputSchema need to return a JsonElement representing your Input Schema
https://www.merge.dev/blog/mcp-tool-schema

[sherlock1982]

Can i make a fully dynamic server? Let's say somebody connects to /mcp/100 and i provide a list of tools somehow?

[eng-marani]

Yes, there are some examples cloning the project. You can even report a different set ot tools depending on the route choosen or some other dynamic conditions.

[ryux1]

There are now two supported patterns on current main, depending on what “dynamic” means.

For a catalog known while the host is being built, create the tools from the reflected methods and pass the metadata through McpServerToolCreateOptions (rather than mutating ProtocolTool afterward):

var tools = configuredMethods.Select(entry =>
    McpServerTool.Create(
        entry.Method,
        request => request.Services.GetRequiredService<MyToolClass>(),
        new McpServerToolCreateOptions
        {
            Name = entry.Name,
            Description = entry.Description,
            SerializerOptions = serializerOptions
        }));

builder.WithTools(tools);

That createTargetFunc overload resolves a fresh target for each invocation and disposes it when appropriate. If names/descriptions are attribute-based, WithTools<MyToolClass>() already performs the per-call DI target creation.

For a catalog that changes after the server starts, configure a shared McpServerPrimitiveCollection<McpServerTool> as McpServerOptions.ToolCollection, then use Add, TryAdd, Remove, or Clear. Empty collections are supported and tools added later become both listable and callable; collection changes also drive the SDK's tool-list change notification path. The repository's end-to-end example is EmptyCollectionTests.EmptyToolCollection_CanAddToolsDynamically, and the collection implementation is here.

One boundary matters for the /mcp/100 example: the configured collection is server-wide. Do not mutate one global collection on each request to represent different users/tenants; concurrent sessions could observe each other's catalogs. Use separate server/configuration instances per route/tenant, or custom list/call handlers backed by an immutable per-request tenant snapshot.