Tools filtering

[Daniel-Kolev]

What I did

Tool filtering

Add new commands: docker mcp tools enable <toolName> and docker mcp tools disable <toolName>. They auto-discover the first matching server using the catalog. Also they accept a --server flag. It helps with duplicate tool names where the auto-discover might fail to find the server the user wants.

The enabled tools are stored in a tools.yaml file which contains all the enabled tools grouped by server. Example file:

curl: []
filesystem:
  - directory_tree
  - get_file_info
  - list_allowed_directories
  - list_directory
  - read_file
  - read_multiple_files
  - search_files

read as:

curl has all of its tools disabled
filesystem has some of its tools enabled
if a server is not mentioned in the file, then all of its tools are enabled

The gateway reads and respects this file. When launching the gateway, the existing --tools option (which accepts the tools names) takes precedence over the tools.yaml file. This works the same way as the --servers option and the registry.yaml.

Nice to haves:

• remove the server entry in the tools.yaml if all of the server's tools are enabled
• report if duplicate tools exist in the catalog and prompt the user to use the --server flag

Related issue

(not mandatory) A picture of a cute animal, if possible in relation to what you did

[Daniel-Kolev]

I could probably give this file a bit more love but this should be good enough for a first iteration of tool filtering

[Daniel-Kolev]

Something I haven't discussed with anyone but want to do is:
Add an "enabled" attribute under each tool in so we could know which tool is enabled/disabled in clients like Docker Desktop. At a first glance, the most appropriate place is docker mcp server inspect which is also what we currently use to list the tools in Docker Desktop. Any thoughts?

EDIT1: We might need another approach if we want to show just the enabled tools count in the servers tab table or the count in the Tools tab when viewing a server

[dgageot]

Hey @cmrigney, I didn't have time to look at Daniel's PR. Could you? Thanks!

[cmrigney]

Nice addition! lgtm, just left a couple optional suggestions.

[cmrigney]

suggestion: I think if I run these tests in VSCode instead of make test (in a container), it will break my local setup right? In that case, it might be a good idea to read the existing file and add a t.Cleanup that re-writes it back to the original.

[Daniel-Kolev]

There's a section in the setup() function that creates a temp directory and replaces the home one with that new temporary one. It gets cleaned up after the tests run so it actually doesn't interfere with your local setup. I did run the test locally and my tools.yaml didn't change.

[cmrigney]

Ohh, totally missed that. Nice! 👍