kubernetes-observability-mcp-server
Related Servers
Alternatives to kubernetes-observability-mcp-server
No user-submitted related servers found.
Related Servers
- AlicenseNot gradedqualityCmaintenanceAn MCP server that enables AI assistants to interact with Kubernetes clusters by translating natural language into kubectl and Helm operations. It allows users to query, manage, and diagnose Kubernetes resources and cluster states through a seamless integration.20Apache 2.0
- AlicenseNot gradedqualityCmaintenanceAn open source MCP server empowering SREs with intelligent observability, predictive analytics, and AI-driven automation across Kubernetes, OpenShift, and Tekton environments.35 PyPI11Apache 2.0
- AlicenseBqualityAmaintenanceA production-grade MCP server providing a secure, natural-language interface to Kubernetes for developers and AI agents, with multi-cluster routing, OIDC authentication, RBAC, and audit logging.7514 npm1MIT
- AlicenseBqualityBmaintenanceA Model Context Protocol (MCP) server that gives AI assistants full visibility and control over Kubernetes clusters.73MIT
- AlicenseNot gradedqualityDmaintenanceAn MCP server that lets AI assistants safely inspect and operate on Kubernetes clusters through natural conversation.18 PyPIMIT
- AlicenseNot gradedqualityDmaintenanceA powerful Model Context Protocol (MCP) server that provides AI assistants with comprehensive access to Dynatrace's observability platform. Features dual authentication architecture, Davis CoPilot AI integration, and 24 specialized tools for monitoring, automation, and operational intelligence.7 npm5MIT
TDQS
Scored across 19 tools
Most tools target a distinct resource+action (list_pods vs describe_pod vs get_pod_logs, namespace events vs namespace health), so selection is generally clear. The main overlap is between debug_dns_config and coredns_health_check, which both cover CoreDNS pod health and could be confused, and the service trio (find_orphaned_services, check_service_endpoints, trace_service_to_pods) sits close together though descriptions differentiate them.
17 of 19 tools follow a verb_noun pattern (list_pods, get_pod_logs, describe_deployment, check_service_endpoints, trace_service_to_pods). Only coredns_health_check and node_network_status break the pattern with noun-first phrasing, a minor deviation that stays readable.
19 tools covers a genuinely broad surface (pods, deployments, events, DNS, network policy, ingress, mesh, Dynatrace), so each largely earns its place. It sits at the heavy end of the comfortable range, and the near-duplicate CoreDNS pair is the one spot that looks like padding.
The observability/network-debugging niche is well covered: pods, deployments, logs, events, health rollups, DNS, ingress, mesh, and Dynatrace correlation. Noticeable gaps are a plain list_services, basic node listing beyond node_network_status, and resource-usage metrics (CPU/memory) that agents would expect from an observability server, though most are workable around via describe commands.