feat(toolsets): add kiali support

[aljesusg]

Adding kiali toolset to kubernetes-mcp

• Adds Kiali toolset with a mesh status tool.
• Requires kiali-url when Kiali is enabled (via flag or config).
• Safer URL building and proper token forwarding to Kiali.(We use the same token to validate permissions and access, so in the local environment we also check the kubeconfig to ensure that the provided context includes valid authentication.)
• Adds focused tests for Kiali manager, client, and mesh.
• Updates help text to list Kiali as an available toolset.

We'll add others later after this first PR

cc @hhovsepy

[matzew]

It would make sense to provide a little document on this, e.g. in here https://github.com/containers/kubernetes-mcp-server/tree/main/docs ?

For instance, when setting the configuration toml to toolsets = ["kiali"] the MCP server would serve those kiali tools, and require the URL where it is running.

[aljesusg]

Sure! I’ll take care of the docs part — I just wanted to get the code reviewed first.
By the way, there’s an error message when the Kiali toolset is enabled without a defined URL.

[manusa]

Looking really good, thank!
I created a PR to your branch with some changes to align the new toolset with the rest of implementations:

aljesusg#2

[aljesusg]

Reviewed and merged. thanks !

[aljesusg]

I’ll remove the flags related with Kiali next day.
Since I see there’s consensus regarding the configuration, I’ll also add the rest of the tools we have.

Thanks

[aljesusg]

Hi! I’ve removed the Kiali configuration and the flags. I’ve also added the rest of the tools that are available so far.

[manusa]

LGTM, thx.

However, a few considerations for follow-up PRs.

This is adding close to 20 new tools which might be sort of overwhelming for many LLMs. Especially because it's likely that this toolset will be enabled along with the standard/core kubernetes toolset.
All in all, only with this domain, ~40 tools will be available for the LLM to choose from.

There is also collision of tools (namespaces_list for example), these are already defined.

We might want to consider some of the tools to avoid it. (e.g. the xxx_traces tools could be easily combined into a single tool, probably the metrics too)

The tool descriptions are kind of vague:

• we might want to prepend the tool names with kiali_ or istio_. e.g. health tool might be very confusing for the LLM
• Some descriptions mention "the mesh", maybe we want to add the Istio word too.

workload_logs: Doesn't this provide similar features as pods_log?

[manusa]

This essentially duplicates what's shown in the main README.md file but it's not automatically generated.
As a follow-up we might want to either generate this automatically, or remove it from here and link to the main readme.

[aljesusg]

LGTM, thx.

However, a few considerations for follow-up PRs.

This is adding close to 20 new tools which might be sort of overwhelming for many LLMs. Especially because it's likely that this toolset will be enabled along with the standard/core kubernetes toolset.
All in all, only with this domain, ~40 tools will be available for the LLM to choose from.

There is also collision of tools (namespaces_list for example), these are already defined.

We might want to consider some of the tools to avoid it. (e.g. the xxx_traces tools could be easily combined into a single tool, probably the metrics too)

The tool descriptions are kind of vague:

• we might want to prepend the tool names with kiali_ or istio_. e.g. health tool might be very confusing for the LLM
• Some descriptions mention "the mesh", maybe we want to add the Istio word too.

workload_logs: Doesn't this provide similar features as pods_log?

Thanks!

Totally agree — we’re happy to simplify things in a follow-up PR. For now, we’ve been experimenting with which tools can provide the most useful information to the LLM, but we’ll definitely review and consolidate them where possible.

Regarding the namespaces overlap, our implementation only returns the namespaces that belong to the mesh, not all Kubernetes namespaces. This distinction is intentional, since the LLM uses it specifically to inspect mesh-related namespaces rather than the full cluster scope.

About the logs — good point! I’ll discuss it with the team, since it’s true that workload_logs already aggregates the logs from the pods, so we could probably remove the pod-level one.

In fact, we’ve noticed that the LLM sometimes makes multiple calls in sequence, so we were already considering grouping some of them. That will definitely be our next step.

Thanks again for the feedback!