AI

• 1: Kiali Chatbot
• 2: Kiali Chatbot tools (schemas)
• 3: Kiali MCP

1 - Kiali Chatbot

Kiali Chatbot is Kiali’s built-in AI assistant in the Kiali UI. It lets you ask questions about your service mesh and get answers backed by live data from Kiali and its configured backends (Prometheus, tracing, Kubernetes, etc.).

It does not require an external MCP server. Kiali includes its own set of MCP-style tools internally, so the AI can call them without depending on a separate MCP deployment.

Status

The Kiali chatbot was first released in Kiali version 2.22 and it is in Dev preview.

How does it work

At a high level:

• The Kiali UI sends your chat request (prompt + context + selected model) to the Kiali backend.
• Kiali selects the configured provider/model from chat_ai.
• The provider calls the LLM with a set of internal MCP tools (defined in Kiali under kiali/ai/mcp).
• The LLM may request tool calls (e.g. mesh graph, traces, resource details, workload logs, Istio config operations).
• Kiali executes those tool calls against Kiali/Kubernetes/Prometheus/tracing backends and returns the final answer, including optional UI navigation actions and documentation citations.
• The response is delivered as streaming events (for example: start, token, tool_call, tool_result, end, error) so the UI can progressively render tokens and tool activity in real time.

For configuration keys (enable/disable, tool filters, providers/models, store), see the chat_ai section in the Kiali CR spec.

Tool schemas (inputs/outputs)

Kiali Chatbot uses internal tools with defined input schemas and structured outputs.

Configuring the Kiali Chatbot

The Kiali Chatbot is disabled by default. To enable it, set chat_ai.enabled: true. When enabled, you will see the chatbot icon in the Kiali UI:

You must also configure at least one provider and model (including an API key), and pick a default provider/model.

Switching model providers

Kiali Chatbot providers and models are configured in chat_ai:

• Providers: OpenAI (type: openai), Google (type: google), Anthropic (type: anthropic), and LightSpeed (type: lightspeed).
• Models are selected by name (per-provider) and can be enabled/disabled.
• API keys can be set inline (not recommended) or via secret:<secret-name>:<key-in-secret>.
• Tool exposure can be filtered globally with chat_ai.tools and further restricted per provider with chat_ai.providers[].tools.

Example configuration (showing three providers: OpenAI, Google, and Anthropic):

chat_ai:
  enabled: true
  default_provider: "openai"
  tools:
    disabled_tools:
      - "manage_istio_config"
  providers:
    - name: "openai"
      enabled: true
      description: "OpenAI provider"
      type: "openai"
      config: "default"
      default_model: "gpt"
      tools:
        enabled_tools:
          - "get_logs"
          - "get_mesh_status"
          - "list_traces"
      models:
        - name: "gpt"
          enabled: true
          model: "<openai-model-name>"
          key: "secret:my-key-secret:openai-api-key"
    - name: "google"
      enabled: true
      description: "Google provider"
      type: "google"
      config: "gemini"
      default_model: "gemini"
      models:
        - name: "gemini"
          enabled: true
          model: "gemini-2.5-pro"
          description: "Model provided by Google with OpenAI API Support"
          endpoint: "https://generativelanguage.googleapis.com/v1beta/openai"
          key: "secret:my-key-secret:google-api-key"
    - name: "anthropic"
      enabled: true
      description: "Anthropic provider"
      type: "anthropic"
      config: "default"
      default_model: "claude-haiku"
      key: "secret:my-key-secret:claude-api-key"
      models:
        - name: claude-sonnet
          model: "claude-sonnet-4-5"
          enabled: true
          endpoint: "https://api.anthropic.com/"
        - name: claude-haiku
          model: "claude-haiku-4-5"
          enabled: true

enabled_tools acts as an allowlist: when set, only the listed tool names are exposed. disabled_tools acts as a denylist and is applied afterwards. You can define these filters globally under chat_ai.tools and/or per provider under chat_ai.providers[].tools. Provider-level filters can only further restrict the already-allowed global toolset.

To see the available built-in tool names you can use in these lists, see Kiali Chatbot tools.

LightSpeed provider example:

chat_ai:
  providers:
    - name: "LightSpeed"
      description: "Openshift LightSpeed"
      type: "lightspeed"
      endpoint: "<LightSpeed endpoint>"
      enabled: true

You can also select the configured models and providers in the chatbot window:

When the assistant uses a tool, Kiali shows a tool-result card directly in the chat so you can see which tool was executed:

You can click the square tool-result card to open the full tool output in a modal window:

In this modal view you can inspect the complete tool response in detail (for example returned resources, metrics, or logs) before continuing the conversation.

Streaming events in the chat

Kiali Chatbot UI updates are powered by server-sent streaming events from the backend. This is why responses appear incrementally (token by token), and why tool usage is shown as it happens.

In practice:

• token events render incremental assistant text.
• tool_call and tool_result events render the tool card and its status/output.
• end finalizes the answer, including optional UI actions and documentation references.
• error reports failures without waiting for a full response timeout.

What you can ask

Examples of tasks that work well:

• Mesh/namespace topology and summaries (graph, status)
• Basic observability questions (metrics, traces)
• Troubleshooting workflows (get logs for a workload, identify failing namespaces)

Example prompts

• “Show me the mesh graph for namespace bookinfo.”
• “Which workloads in istio-system look unhealthy and why?”
• “Get traces for service productpage in bookinfo for the last 30m.”

Next step

If you want to use an AI assistant outside the Kiali UI (for example, in an IDE), see Kiali MCP.

2 - Kiali Chatbot tools (schemas)

Kiali Chatbot uses internal MCP-style tools (implemented inside Kiali) to fetch live data and perform safe actions. These are not external MCP server tools.

Administrators can control which of these tools are exposed to the AI by using chat_ai.tools for global filtering and chat_ai.providers[].tools for provider-specific filtering. Use the exact tool names below in enabled_tools and disabled_tools.

The tool input schemas are defined in Kiali under kiali/ai/mcp/tools/*.yaml. The tool outputs are JSON structures returned by the Kiali backend and consumed by the model and/or UI.

Tool list

• get_action_ui: returns UI navigation actions (buttons/links).
• get_logs: returns workload or pod logs with optional filtering.
• get_mesh_status: returns high-level mesh health, control plane, observability stack, and connectivity status.
• get_mesh_traffic_graph: returns a compact service-to-service traffic topology with metrics such as throughput, response time, and mTLS.
• get_metrics: returns Istio or Envoy metrics for services, workloads, or apps.
• get_pod_performance: returns current pod CPU and memory usage versus requests and limits.
• get_referenced_docs: returns relevant Istio and Kiali documentation links.
• get_trace_details: returns the hierarchy and span details for a specific trace.
• list_or_get_resources: lists resources or returns details for services, workloads, apps, and namespaces.
• list_traces: returns a compact list of distributed traces for a service.
• manage_istio_config_read: lists or gets Istio config in read-only mode.
• manage_istio_config: creates, patches, or deletes Istio config with a confirmation flow for sensitive actions.

3 - Kiali MCP

Kiali MCP is an integration that allows MCP-capable AI assistants to query (and optionally manage) Kiali-related data by calling tools exposed by an MCP server.

The implementation is provided as part of the Kubernetes MCP Server upstream and also for Openshift MCP server. It exposes a kiali toolset (see upstream guide: docs/KIALI.md).

Prerequisites

• A reachable Kiali endpoint (Route/Ingress/Service URL).
• Kubernetes credentials available to the MCP server (kubeconfig or in-cluster config).

Enable the kiali toolset

Create a TOML config file and enable kiali in toolsets.

toolsets = ["core", "kiali"]

[toolset_configs.kiali]
url = "https://kiali.example" # Endpoint/route to reach the Kiali console
# insecure = true  # optional: allow insecure TLS (not recommended in production)
# certificate_authority = "/path/to/ca.crt"  # CA bundle for Kiali's TLS cert

Notes:

• If url is https:// and insecure = false, you must provide certificate_authority.
• Authentication to Kiali is performed using the server’s Kubernetes credentials (it obtains/uses a bearer token for Kiali calls).

Connect from an MCP client

How you wire this into a specific client depends on the client, but the core idea is the same: start the MCP server with your kubeconfig and your TOML config.

Example (conceptual) command:

kubernetes-mcp-server --config /path/to/config.toml --read-only

Once connected, your assistant can use the Kiali tools (for example: mesh graph, metrics, traces, workload logs) to power a chatbot-like experience outside the Kiali UI (for example, in an IDE).