Skip to content

Sveltos MCP Server

Video

To learn more about the Sveltos MCP Server, check out the Video! 😊

Sveltos has an integrated Model Context Protocol (MCP) server that connects AI assistants and chatbots to the Sveltos management cluster. It provides a structured, programmatic interface that allows AI agents to interact with Sveltos using natural language. This enables powerful features such as automated troubleshooting, real-time cluster analysis, and streamlined operational tasks across all the clusters Sveltos manages.

Enterprise Feature

You can test the Sveltos MCP Server directly from the Sveltos dashboard to verify your Sveltos installation and diagnose failures on a given cluster. To integrate the Sveltos MCP Server with AI Site Reliability Engineering (SRE) tools, contact us at support@projectsveltos.io to discuss licensing options.

How does it work?

The Sveltos MCP Server acts as a communication layer between AI agents and the Sveltos-managed infrastructure. Instead of an AI directly executing kubectl commands on individual clusters, it sends requests to the MCP Server using the MCP. The server then translates these high-level requests into specific Sveltos tool calls.

The described process is not a simple command translation; it involves performing comprehensive checks on cluster statuses, the state of the Sveltos deployments, and the state of the Sveltos Custom Resources. Additionally, the server correlates the state of different resources that are tied to each other, providing a holistic view of the system's health. By consolidating these checks, the MCP Server provides a single, unified result to the AI, which can then present the findings to a user in a clear, conversational format.

This abstraction allows AI to perform complex operations, such as diagnosing deployment failures or comparing cluster configurations, with a single, high-level instruction, making Sveltos a powerful tool for automated, multi-cluster management.

Key Capabilities

The Sveltos MCP Server empowers AI with the ability to:

  • Verify Installation Health: The AI can instantly check the health of all Sveltos components on the management cluster and confirm that agents are correctly deployed — either in each managed cluster or running centrally in the management cluster in agentless mode. This is the best starting point when something looks wrong.

  • Analyze Cluster State: The AI can read the operational status of all Sveltos-managed clusters, including the health of Sveltos agents and the state of deployed resources. It can list every managed cluster, filter by label selector (e.g. env=production), and get a single source of truth for your entire fleet.

  • Inspect Deployed Resources: The AI can list all Kubernetes resources and Helm charts that Sveltos has successfully deployed on a given cluster, or instantly surface all deployment failures without having to inspect individual profiles one by one.

  • Automate Troubleshooting: When a user reports an issue, the AI can use the MCP Server's tools to perform diagnostic checks automatically. For example, it can call the analyze_profile_deployment tool to investigate a deployment failure, identify the specific error, and provide a resolution plan. It can also list every ClusterProfile and Profile targeting a cluster with per-feature status (Helm, Resources, Kustomize) and pending dependencies.

  • Diagnose in One Call: Instead of running the troubleshooting steps one after the other, the AI can call diagnose_cluster or diagnose_profile. diagnose_cluster checks that the cluster is ready and not paused, the Sveltos agents, every feature of every profile that is not yet Provisioned (with the message recorded in the status), the resources the profiles reference, the pending updates and, when they apply, pull mode and configuration drift. diagnose_profile checks a profile on all the clusters it matches and groups the clusters that fail the same way, so a failure on 200 clusters is one finding with a count and a few examples. Both return the findings, most severe first, each naming the tool that goes deeper, and a summary of what is healthy.

  • Read What Sveltos Reported: When the status of a resource has no explanation, the AI can call list_sveltos_events to get the Kubernetes events Sveltos components recorded: failed feature deployments, failed health check notifications, failed event triggers, classifier failures and conflicts, clusters that became unreachable or recovered, and the stages of a ClusterPromotion. Identical events are grouped with a count, and the AI can limit the result to one object. Kubernetes keeps events for about one hour, so the tool reports recent failures only.

  • Deep-Dive into Helm and Kustomize: The AI can retrieve detailed information about a specific Helm release — combining Sveltos metadata with the actual Helm state from the workload cluster (deployed, failed, pending-upgrade, user values) — or verify that every Flux source (GitRepository, OCIRepository, Bucket) and plain source (ConfigMap, Secret) referenced by Kustomize profiles exists and is ready. It can also list the Helm releases Sveltos manages on a cluster that have a newer version, or a newer patch, published upstream.

  • Trace Profile Dependencies: The AI can walk the full DependsOn chain of a profile on a cluster and identify the root-cause node when a profile is stalled because a dependency is not yet provisioned.

  • Analyze Pull Mode Deployments: For a cluster in pull mode the management cluster does not connect to the managed cluster, so a deployment that does not complete has causes that do not show up as in push mode. The AI can check the heartbeat of the sveltos-applier and the failure it reported, and each ConfigurationGroup: still being prepared, not yet processed by the applier, or failed with a message. It can also tell which Helm releases the applier is asked to apply and which it skips because they did not change. It only reads the management cluster.

  • Report Configuration Drift: The AI can answer which resources drifted, when, and whether Sveltos already corrected the drift, for a cluster, a profile or both. For a profile without a record it says why: drift detection is not enabled, or nothing drifted. See Configuration Drift.

  • Ensure Configuration Consistency: The compare_managed_clusters tool allows AI to proactively monitor for configuration drift between clusters. It can quickly identify what is common, different, or unique across two clusters and alert operators to potential compliance issues or misconfigurations.

  • Streamline Operations: The server's tools enable AI to handle routine operational tasks, such as listing profiles whose updates are currently queued (and whether the hold is due to a suspended cluster or a MaxUpdate throttle), or previewing the changes that DryRun-mode profiles would apply before committing to live deployment. This frees up human operators to focus on more complex tasks.

  • Trace Event-Driven Deployments: The AI can follow an event-driven deployment end-to-end — from EventSource detection on the managed cluster, through EventTrigger evaluation, to the creation and deployment of the resulting dynamic ClusterProfile — and identify exactly where the chain breaks, including surfacing the specific error when event-manager fails to instantiate a ClusterProfile from an EventReport, instead of leaving the user to infer it from a missing profile. It can also list all ClusterProfiles dynamically created by EventTriggers and map each back to its originating event.

  • Trace Classifier Pipelines: The AI can trace either a Classifier or a ManagementClusterClassifier instance against a specific cluster by name alone, without needing to know which kind it is. For a Classifier, it reports whether the cluster currently matches, the agent report delivery phase, deployment status, and label ownership/conflicts. For a ManagementClusterClassifier (which evaluates resources on the management cluster itself rather than deploying anything to managed clusters), it reports cluster match, any reconcile failure (invalid Lua, resource collection errors), and the same label ownership/conflict detail. A separate fleet-wide tool lists every label currently being managed by any Classifier or ManagementClusterClassifier across all, or a filtered subset of, managed clusters, along with which instance owns each label and where two instances are conflicting over the same key, mirroring sveltosctl show classifier-labels.

  • Monitor Health Checks: The AI can trace the full health-check pipeline for a cluster: validating that ClusterHealthCheck selectors match, confirming HealthCheck resource distribution, inspecting HealthCheckReports for resource-level results (Healthy, Degraded, Progressing), and reporting notification delivery status.

  • Manage Progressive Delivery: The AI can list all ClusterPromotion pipelines with their current stage and whether any pipeline is blocked waiting for manual approval. It can also provide a detailed per-stage breakdown of a single pipeline — selector, trigger type, approval state, timing configuration, and runtime status — so it can explain exactly what is blocking a promotion.

Available Tools

The AI picks the tool by the question being asked.

Tool Use it to
installation_status Verify the health of the Sveltos components in the management cluster and of the Sveltos agents in the managed clusters.
list_managed_clusters List the managed clusters with their readiness, whether they are paused or in pull mode, and the health of their agents.
list_clusters_by_selector List the managed clusters that match a label selector.
compare_managed_clusters Compare the Kubernetes resources and Helm releases of two clusters.
diagnose_cluster Check a cluster in one call and get the findings, most severe first.
diagnose_profile Check a ClusterProfile or Profile on all the clusters it matches in one call.
list_deployed_resources List the Kubernetes resources and Helm charts Sveltos deployed on a cluster.
list_profiles_for_cluster List every ClusterProfile and Profile targeting a cluster, with the status of each feature and the pending dependencies.
list_deployement_errors List what failed to deploy on a cluster.
get_helm_release_details Get the details of one Helm release, combining the Sveltos data with the Helm state in the managed cluster.
list_outdated_helm_charts List the Helm releases on a cluster that have a newer version published upstream.
list_configuration_drift Get the configuration drift history recorded for a cluster, a profile or both: which resources drifted and when.
get_cluster_health List the resources that health monitoring reports as not healthy on a cluster, with the profile that owns each of them.
list_sveltos_events List the Kubernetes events Sveltos recorded, such as failed deployments, failed notifications and unreachable clusters, grouped with a count.
analyze_profile_deployment Analyze the deployment of a profile on a cluster.
analyze_profile_cluster_match Explain why a cluster does or does not match a profile.
analyze_profile_dependencies Trace the DependsOn chain of a profile and find the profile that blocks it.
list_pending_profiles_for_cluster List the profiles whose update to a cluster is pending, because the cluster is suspended or because of a MaxUpdate throttle.
analyze_kustomize_deployment Check that the sources referenced by Kustomize profiles exist and are ready.
list_dryrun_changes_for_cluster Preview what profiles in DryRun mode would change.
analyze_pull_mode_deployment Find out why a deployment to a cluster in pull mode does not complete.
analyze_event_deployment_pipeline Trace an event-driven deployment from the EventSource to the deployed resources.
list_triggered_profiles List the ClusterProfiles created by EventTriggers.
analyze_healthcheck_pipeline Trace the health check pipeline of a cluster, up to the notifications.
analyze_classifier_pipeline Find out why a cluster is not labeled as a Classifier or ManagementClusterClassifier expects.
list_classifier_managed_labels List the labels managed by classifiers across the clusters, and the conflicts.
list_cluster_promotions List the ClusterPromotion pipelines, and the ones that failed or wait for approval.
analyze_cluster_promotion Analyze one ClusterPromotion pipeline stage by stage.

Integrated Dashboard Functionality

The Sveltos dashboard is designed to enhance users' troubleshooting experience by integrating a built-in Sveltos MCP client. The client connects directly to the Sveltos MCP server, providing powerful diagnostic capabilities right from the user interface.

The integrated client can:

  • Debug Sveltos Installation: Instantly verify the health of the Sveltos installation on the management cluster. The client talks to the server, which runs comprehensive checks to ensure all Sveltos components are running correctly. It also verifies and checks the status of the Sveltos agents deployed across all the managed clusters. This ensures that every cluster is properly configured and communicating with the management cluster.

  • Diagnose Deployment Issues: The dashboard can be used to pinpoint deployment problems on any Sveltos managed cluster. The MCP client sends a request to the server, which analyzes the state of Sveltos' resources and deployments, and returns a detailed report on any failures or inconsistencies.

🎥 Dashboard MCP Video

The seamless integration transforms the dashboard from a simple monitoring tool into a proactive, powerful debugging console, leveraging the full capabilities of the Sveltos MCP server to simplify multi-cluster management.

Kubernetes Deployment Details

The Sveltos MCP Server is deployed in the projectsveltos namespace.

  • Deployment: mcp-server
  • Service: mcp-server

The service type is ClusterIP, which means it is only accessible from within the cluster. If you need to expose the Sveltos MCP Server to external clients, you'll need to change the service type from ClusterIP to a different type, such as LoadBalancer or NodePort.