Add support for more flexible custom tool definitions and loading mechanisms

[hakman]

At the moment, kubectl-ai supports a single YAML file for defining custom tools, added in https://github.com/GoogleCloudPlatform/kubectl-ai/pull/223. It would be beneficial to expand this by supporting:

• CLI flags to specify tool configs (e.g., --tools-conf and/or --tools-dir), with support for one or multiple locations.
• ability to load custom tools from both a single YAML file (containing tool definitions) and a directory of individual YAMLs (one per tool, e.g., helm.yaml, nomos.yaml).
• automatic detection of whether a file is a collection or single tool definition. This will help with sharing and distributing tool definitions and future-proof the UX for upcoming features such as auto-generating tool manifests.

If there consensus that this is a good feature request, I would be happy to work on adding it.

/cc @droot @janetkuo @justinsb

[droot]

Fully supportive of all the above. tools extensibility can increase the utility of kubectl-ai significantly and it may take a few iterations to get the config options nailed down.

This also have some overlap with mcp integration work that we want to pursue. mcp is just another way to discover tools (and other stuff like prompts). Don't know the exact shape of how tools discovered through mcp and our custom mechanism will merge, but worth spending some cycles on it.

[hakman]

Thanks @droot, fully agree with your comment. I also look forward to the mcp integration and experimenting with it.

[janetkuo]

This sounds good. Suggest reusing the same flag --custom-tools-config for both a single file or folder if possible.

This will help with sharing and distributing tool definitions and future-proof the UX for upcoming features such as auto-generating tool manifests.

I like this idea. Perhaps we can have a community curated list of custom tools config (for popular tools) in this repo as examples.

[droot]

Suggest reusing the same flag --custom-tools-config for both a single file or folder if possible.

@janetkuo I think we can drop custom- prefix because tools-dir or --tools-conf conveys the intent pretty well and are shorter. We can change existing flags (aliasing is possible to keep it backward compatible or even breaking at this stage is okay).

[janetkuo]

The reason I added custom- is because this makes it more clear that the configuration can't touch built-in ones. For example you can't use it to overwrite function definitions of kubectl.

[hakman]

@janetkuo Overriding the built-in tools would be a good use case. For example, using bash is nice to play around. I would not make it available for more sensitive environments, where only a fixed set of tools should be available. Sure, kubectl is the core and could remain built-in, but bash and trivy are not mandatory. My guess is that people that add their own tools, could copy the kubectl, bash and trivy config file to their tools dir, as needed.

[janetkuo]

I'm fine with supporting overriding built-in tools, as long as the flag name we choose is consistent with the behavior. We will need to think through the implications before adding the overriding support.

Either way, for better UX, we should reuse the same flag instead of creating an additional one like tools-dir. For example, kubectl apply -f accepts both a file and a folder.

[hakman]

OK, will go slow and see where this leads.