Disabling tools

[Kyu]

For the use case where one only needs access to certain tools. e.g me, I need read only access, I dont want write access, and I don't want misc tools enabled.

For stdio, I can see the caller passing a --disabled or similar flag that takes an array of tool names. I think SSE would be similar, but I don't use it, so not sure.

In the WithSharpTools builder extension we can then filter by tool name before returning the builder. I was going to make a PR but wanted to get thoughts first.

Thanks for the tool btw, its incredibly useful

[kooshi]

I'm glad you like it!

I also frequently need it in read-only mode. I usually disable the tools manually by unchecking them in whatever client I'm using, but it would absolutely be useful to have a --read-only flag, as well as some sort of filter args in case a client doesn't support manually disabling them, or if you always want one disabled for one reason or another.

I think to apply the filtering, we need to use a different mechanism to populate the tools. Right now, it uses simple, built in, reflection based enumeration.

There's a more manual method available in the C# MCP SDK. I haven't looked into what it would take to migrate to it, but I keep running into more reasons to use it, and I doubt it would be hard.

[kooshi]

See here:

https://github.com/modelcontextprotocol/csharp-sdk

At the bottom of the readme it shows a much lower level tool definition, but I believe there's a middle ground. Ideally I'd like to avoid re-implementing their reflection enumeration, and just build on top of it.

[Kyu]

I believe we can filter at the Assembly.Load point.

for each symbol in toolAssembly, we can check if its annotated by McpServerTool, then if the method name matches our filter, we can skip. For the ones we didnt skip, we can do builder.withTools(validSymbols[]) to load the array

and agreed, doing their low level one is wayy too much

public static IMcpServerBuilder WithSharpTools(this IMcpServerBuilder builder) {
        var toolAssembly = Assembly.Load("SharpTools.Tools");

        return builder
            .WithToolsFromAssembly(toolAssembly)
            .WithPromptsFromAssembly(toolAssembly);
    }

[Kyu]

looking at how WithToolsFromAssembly, it would be something similar to

    public static IMcpServerBuilder WithToolsFromAssembly(this IMcpServerBuilder builder, Assembly? toolAssembly = null, JsonSerializerOptions? serializerOptions = null)
    {
        Throw.IfNull(builder);

        toolAssembly ??= Assembly.GetCallingAssembly();

        return builder.WithTools(
            from t in toolAssembly.GetTypes()
            where t.GetCustomAttribute<McpServerToolTypeAttribute>() is not null
            // -- and someMatchingFilter(t.Name) or even someMatchingFilter(t.Module.Name) --
            select t,
            serializerOptions);
    }

[kooshi]

You're right, and actually, it may be worth submitting a PR to the SDK to extend the signature of WithToolsFromAssembly (and the other WithXFromAssembly methods) to add an optional include delegate argument.

The delegate would take in the tool, and return a boolean.

I believe it is generally useful enough that they may accept it.

I would just need to double check that there isn't already a more elegant way to achieve it. I'm certain there are a few other ways to enumerate the tools in that library, but maybe I'm misremembering.

[kooshi]

Ok, I looked at the code to remember what I was thinking about.
https://github.com/modelcontextprotocol/csharp-sdk/blob/main/src/ModelContextProtocol/McpServerBuilderExtensions.cs
The ServerBuilder provides a lot of functionality.
I think this could be achieved with one or a combination of:

• WithTools
• WithListToolsHandler
• AddListToolsFilter

However, I do think a filter on WithToolsFromAssembly is actually the most elegant solution.

Again, ideally I'd like for the SDK to directly support what we want to do here, because I suspect we won't be the only ones that want it, but I'm not against just rigging it up locally since it's such a simple change.

[Kyu]

Def agreed that it would be a good upstream feature. Do you want to create the request, or should I?