Kiali Refactor from v2.24

[aljesusg]

Ready

Summary

• Refactors all Kiali MCP tools to delegate execution to Kiali's backend /api/chat/mcp/* endpoints instead of implementing the logic locally
• Removes ~3,000 lines of duplicated Go code that replicated Kiali-internal logic (health calculation, graph assembly, trace formatting, log retrieval, Istio config management)
• Adds comprehensive test coverage for the Kiali HTTP client and config validation

Motivation

Kiali's UI already ships a built-in chatbot that uses the same MCP tool semantics. Maintaining two independent implementations of the same tools — one in the Kiali backend and one here in the MCP server — created several problems:

1. Duplicated logic: Health calculation, graph assembly, trace summarization, and Istio config management were reimplemented in this repository, diverging from Kiali's canonical behavior over time.
2. Version skew: Output formats and default parameters drifted between the Kiali UI chatbot and the MCP server, producing inconsistent experiences.
3. Large tool schemas and responses: Each tool carried verbose input schemas and produced large JSON responses because the MCP server had to expose every upstream parameter and return raw API data.
4. Limited CI coverage: Complex Kiali-specific logic (e.g., health status rollup across namespaces) was hard to integration-test without a live Kiali instance.

What changed

Architecture

Before: each tool handler built REST API calls to multiple Kiali endpoints, parsed JSON responses, computed derived data (health rollups, graph merges), and formatted output.

After: each tool handler is a thin wrapper that POSTs to <kiali-url>/api/chat/mcp/<tool_name> with the tool arguments as JSON. Kiali's backend owns all data fetching, aggregation, and LLM-optimized formatting.

Deleted (~3,000 lines)

• pkg/kiali/: 15 files removed — health_calculation.go (626 lines), get_mesh_graph.go, graph.go, traces.go, logs.go, services.go, workloads.go, istio.go, mesh.go, namespaces.go, validations.go, types.go, endpoints.go, etc.
• pkg/toolsets/kiali/: 7 files removed — get_mesh_graph.go, get_metrics.go, get_resource_details.go, get_traces.go, helpers.go, helpers_test.go, logs.go, manage_istio_config.go

Added

• pkg/toolsets/kiali/tools/: 9 thin tool handlers (~60–90 lines each) that define the tool schema and delegate to kiali.ExecuteRequest()
• pkg/toolsets/kiali/tools/endpoints.go: centralized MCP endpoint path constants
• pkg/toolsets/kiali/internal/defaults/: shared default values for tool parameters
• pkg/kiali/tests/: endpoint coverage test ensuring every endpoint constant is wired to a tool implementation, plus backend contract test scaffolding

Improved test coverage

• kiali_test.go: no-config initialization, empty endpoint, non-2xx error handling (with/without body), JSON body serialization, header assertions (Content-Type, X-Kubernetes-MCP-Server, POST method), Bearer token edge cases (empty, already-prefixed)
• config_test.go: direct Validate() tests for nil config, empty URL, invalid URL, URL without scheme, HTTP vs HTTPS certificate requirements
• pkg/mcp/kiali_test.go: rewritten to test the new architecture (single POST per tool, MCP endpoint paths, JSON argument forwarding)

Benefits

• Smaller tool schemas — input schemas only expose what the LLM needs; Kiali handles defaults and validation server-side
• Smaller responses — Kiali returns pre-formatted, LLM-optimized text instead of raw JSON that the MCP server had to post-process
• Single source of truth — tool behavior is controlled by the Kiali release, eliminating version skew with the Kiali UI chatbot
• Better testability — Kiali tests all tool logic in its own CI with full integration tests against a live mesh
• Simpler maintenance — adding or modifying a tool requires changes only in the Kiali backend; the MCP server just needs a thin handler and endpoint constant

Test plan

• make test passes (all 25 packages green)
• Endpoint coverage test verifies every endpoint constant is used by a tool
• Kiali HTTP client fully tested (auth, headers, error codes, body serialization, response limits)
• Config validation fully tested (nil, empty, invalid URL, HTTP/HTTPS cert logic)
• MCP integration tests verify tool registration, correct endpoint routing, and response forwarding

[aljesusg]

Hi @Cali0707 thanks for the review. You're right.

We are still working on it, which is why we marked it as WIP, and it's likely we'll find something else. We won't be able to verify everything until Kiali 2.24 is released next Monday.

[aljesusg]

Hi @Cali0707 ! This isr eady. Can we run it?

[Cali0707]

/run-mcpchecker kiali

[github-actions]

mcpchecker MCP Evaluation Results

Commit: fcbcaf8
Summary: 18/26 tasks passed (69.2%)

Metric	Result
Tasks Passed	18/26
Assertions Passed	78/78
Overall	❌ Failed

View full results

[Cali0707]

Overall this refactor looks fine to me. I also understand the concerns around duplicated logic for these tools.

I guess my only two worries would be around if there will be any issues with versioning this MCP server vs. the kiali one (what happens if the kiali backend updates and has different params, but the user doesn't update the MCP server or vice-versa?), as well as how the kiali endpoint mixes with the multi cluster support

One interesting approach we have seen downstream is having the toolset be an external dependency that is imported into the server, maybe that would be another option that would at least solve the versioning issues?

cc @matzew @manusa - not sure what y'all think

[Cali0707]

@aljesusg does this approach work with any of the multi cluster work in the MCP server? Or is this going to always go to a specific kiali instance?