kube-diagnostics-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| DIAG_MODE | No | hub or probe | hub |
| DIAG_POD_NAME | No | Pod name (used by probe, typically from downward API) | |
| DIAG_HTTP_HOST | No | hub HTTP bind | 0.0.0.0 |
| DIAG_HTTP_PORT | No | hub HTTP bind | 8090 |
| DIAG_LOG_LEVEL | No | debug, info, warn, error (stderr only; stdout is the MCP stream in stdio mode) | info |
| DIAG_TRANSPORT | No | hub: stdio or http | stdio |
| DIAG_HTTP_TOKEN | No | bearer token MCP clients must present (required for http unless DIAG_HTTP_ALLOW_UNAUTHENTICATED=true) | |
| DIAG_NAMESPACES | No | comma-separated allow-list of namespaces | all |
| DIAG_PROBE_HOST | No | Probe listen host (default pod IP) | |
| DIAG_PROBE_PORT | No | how the hub finds probes | 9911 |
| DIAG_SPLUNK_URL | No | Splunk base URL (e.g., https://splunk.example.com:8089) | |
| DIAG_PROBE_TOKEN | No | shared hub↔probe token | |
| DIAG_DATADOG_SITE | No | Datadog site (e.g., datadoghq.eu) | datadoghq.com |
| DIAG_SPLUNK_INDEX | No | Splunk index to search | |
| DIAG_SPLUNK_TOKEN | No | Splunk authentication token (alternative: DIAG_SPLUNK_TOKEN_FILE) | |
| DIAG_DATADOG_SCOPE | No | Additional tags to add to every Datadog query (e.g., env:prod) | |
| DIAG_LOG_MAX_BYTES | No | per-pod log fetch cap in bytes | 262144 |
| DIAG_LOG_MAX_LINES | No | per-pod log fetch cap in lines | 500 |
| DIAG_POD_NAMESPACE | No | Pod namespace (used by probe, typically from downward API) | |
| DIAG_K8S_TIMEOUT_MS | No | Kubernetes API call timeout in milliseconds | 15000 |
| DIAG_PROMETHEUS_URL | No | Prometheus provider URL (e.g., http://prometheus:9090) | |
| DIAG_DATADOG_API_KEY | No | Datadog API key (alternative: DIAG_DATADOG_API_KEY_FILE) | |
| DIAG_DATADOG_APP_KEY | No | Datadog Application key (alternative: DIAG_DATADOG_APP_KEY_FILE) | |
| DIAG_MAX_RESULT_BYTES | No | per-tool result cap in bytes | 204800 |
| DIAG_PROBE_STATIC_DIR | No | Path to static Angular build directory for bundle stats | |
| DIAG_PROBE_TIMEOUT_MS | No | probe call timeout in milliseconds | 5000 |
| DIAG_PROM_HTTP_METRIC | No | Prometheus HTTP metric name for golden signals (default http_server_requests_seconds) | |
| DIAG_DEFAULT_NAMESPACE | No | used when a tool call omits namespace (defaults to the single allow-listed namespace) | |
| DIAG_PROBE_RUM_ENABLED | No | Enable real-user monitoring beacon ingest | false |
| DIAG_SPLUNK_TOKEN_FILE | No | Path to a file containing the Splunk token | |
| DIAG_SPLUNK_VERIFY_TLS | No | Set to 'false' for self-signed TLS certificates | true |
| DIAG_PROBE_ACTUATOR_URL | No | Base URL of Spring Boot Actuator (e.g., http://127.0.0.1:8080/actuator) | |
| DIAG_PROM_SERVICE_LABEL | No | Prometheus label identifying service name | |
| DIAG_SPLUNK_AUTH_SCHEME | No | Set to 'Splunk' for session key authentication instead of a token | Bearer |
| DIAG_ALLOW_ACTIVE_CHECKS | No | enable DNS/TCP/HTTP/TLS checks that generate traffic | false |
| DIAG_DATADOG_LOG_INDEXES | No | Comma-separated list of log indexes to limit log search | |
| DIAG_DATADOG_SERVICE_TAG | No | Datadog tag used to identify the service | service |
| DIAG_DATADOG_API_KEY_FILE | No | Path to a file containing the Datadog API key | |
| DIAG_DATADOG_APP_KEY_FILE | No | Path to a file containing the Datadog Application key | |
| DIAG_PROBE_CONTAINER_NAME | No | how the hub finds probes | diag-probe |
| DIAG_SPLUNK_SERVICE_FIELD | No | Field name for service/container in Splunk events | container_name |
| DIAG_DATADOG_APM_OPERATION | No | Span name whose trace metrics carry request rate and latency (e.g., servlet.request for Java/Spring, http.request for others) | servlet.request |
| DIAG_DATADOG_NAMESPACE_TAG | No | Datadog tag used to identify the Kubernetes namespace | kube_namespace |
| DIAG_PROBE_ACCESS_LOG_PATH | No | Path to nginx JSON access log for summarization | |
| DIAG_PROBE_NGINX_STATUS_URL | No | URL of nginx stub_status (e.g., http://127.0.0.1:8081/stub_status) | |
| DIAG_SPLUNK_NAMESPACE_FIELD | No | Field name for Kubernetes namespace in Splunk events | namespace |
| DIAG_DATADOG_RUM_APPLICATION | No | Filters RUM to a specific application | |
| DIAG_PROBE_RUM_MAX_BODY_BYTES | No | Maximum body size for RUM beacons | 8192 |
| DIAG_SPLUNK_REQUEST_LOG_SEARCH | No | Search query that selects request log events (e.g., sourcetype="nginx:json") | |
| DIAG_SPLUNK_REQUEST_PATH_FIELD | No | Field name for request path in request logs | |
| DIAG_HTTP_ALLOW_UNAUTHENTICATED | No | If true, allows unauthenticated HTTP access (alternative to setting DIAG_HTTP_TOKEN) | false |
| DIAG_PROBE_ALLOW_UNAUTHENTICATED | No | Allow unauthenticated probe access (development only) | false |
| DIAG_PROBE_RUM_RETENTION_MINUTES | No | How long to keep RUM aggregates in memory | 360 |
| DIAG_SPLUNK_REQUEST_METHOD_FIELD | No | Field name for HTTP method in request logs | |
| DIAG_SPLUNK_REQUEST_STATUS_FIELD | No | Field name for HTTP status in request logs | |
| DIAG_SPLUNK_REQUEST_DURATION_FIELD | No | Field name for request duration in request logs |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_providersA | Show which signal providers (metrics-server/probe, Prometheus, Datadog, Splunk) are configured and reachable, and what each can answer. Read-only. |
| list_namespacesA | List namespaces this hub may inspect. Read-only. |
| list_workloadsA | Deployments/StatefulSets/DaemonSets/Jobs/CronJobs in a namespace with ready counts, restarts, images, and age. Start here when you do not know what runs where. |
| get_topologyB | Service -> pods -> workload graph plus inferred dependencies (from env/ConfigMap references to Service names, and from probe-observed connections if include_connections=true). Flags Services with no ready endpoints. |
| get_service_overviewA | One-call digest for a service: replicas, pod problems, recent warning events, usage vs requests/limits, golden signals if available. The first tool to call for 'is X healthy?'. |
| get_pod_statusA | Pod phases, container states and waiting/terminated reasons (CrashLoopBackOff, OOMKilled, ImagePullBackOff...), restart counts, exit codes, unschedulable conditions. Give a service, a pod, or neither for the whole namespace. |
| get_eventsA | Kubernetes events, warnings first, deduplicated with counts. Filter by object name prefix. |
| get_logsA | Sanitized, size-capped container logs for a service (up to 10 pods) or a pod. Use previous=true for the crashed container. grep accepts a substring or /regex/i. |
| summarize_log_errorsA | Groups ERROR (and optionally WARN) log lines by signature (Java stack traces by exception + first app frame) with counts, first/last seen, and one redacted sample each. Read this instead of raw logs. |
| get_configA | Resolved configuration of a workload: env (secret-sourced values shown as references, credential-looking keys redacted), ConfigMap previews, probes, resources, mounts, security context, plus findings (secrets in env, missing probes, JVM heap vs limit...). |
| get_rollout_historyB | Deployment revisions with image/env/resource diffs between them. Answers 'what changed in the last deploy?'. |
| what_changedB | One timeline of rollouts, scaling, HPA actions, ConfigMap updates, restarts, and notable events in a window. The first question in any incident. |
| get_resource_pressureB | CPU/memory usage vs requests and limits per container, CFS throttling ratio when known, OOM kills, restarts, with findings. |
| compare_replicasA | Is one replica the outlier? Per-pod usage, restarts, node, revision hash; flags hot pods, leaks, stuck rollouts, and no node spread. |
| get_node_pressureC | Node conditions (Memory/Disk/PID pressure), allocatable vs requested vs used, overcommit, taints, cordons. |
| get_hpa_statusB | HorizontalPodAutoscalers: current/target metrics, at-max, unable-to-scale conditions. |
| get_golden_signalsB | Request rate, error rate, latency percentiles (and per endpoint) from the best available provider: Prometheus (windowed) or Actuator via the probe (cumulative). |
| query_metricsA | Escape hatch: raw PromQL range query against the configured Prometheus, compacted (first/last/min/max/avg + 12 samples per series). |
| find_slow_tracesB | Slowest traces for a service from the tracing provider (none configured yet: returns guidance). |
| get_traceC | Critical-path view of one trace (needs a tracing provider). |
| get_endpointsB | Service -> EndpointSlice: matching pods, ready endpoints, targetPort vs containerPort mismatches. Catches the classic 'selector matches nothing'. |
| get_network_policiesA | NetworkPolicies in a namespace, decoded; whether a given workload's ingress/egress is restricted; flags 'no policy = wide open'. |
| get_ingress_routesB | Ingress hosts/paths -> Services, TLS coverage, dangling backends. |
| get_open_connectionsA | [probe] Established connections by destination (resolved to Services/pods), socket state counts (TIME_WAIT/CLOSE_WAIT storms), listening ports - from /proc/net inside the pod's network namespace. Passive. |
| get_listening_portsB | [probe] What the application actually binds (vs what the Service targets). |
| resolve_dnsB | [probe, ACTIVE] Resolve a name from inside the pod (its resolv.conf, search domains, ndots). Requires DIAG_ALLOW_ACTIVE_CHECKS. |
| check_connectivityB | [probe, ACTIVE] TCP connect from inside the pod to host:port with latency and a diagnosis of the failure mode. Requires DIAG_ALLOW_ACTIVE_CHECKS. |
| get_process_statsA | [probe] RSS, threads, file descriptors vs limit, state, uptime per process (needs shareProcessNamespace on the pod to see the app). |
| get_jvm_healthA | [probe] Heap used/committed/max vs container limit, GC pause count/total/max, threads, classes, CPU seen by the JVM - from Actuator on localhost. |
| get_thread_dump_summaryB | [probe] Actuator threaddump reduced to: threads by state, pool busy/total, lock contention, DEADLOCK detection, top stack signatures. Never the raw dump. |
| get_connection_pool_statusB | [probe] HikariCP active/idle/pending/max, acquire and usage times, timeouts. Pool exhaustion is the #1 Java+DB slowness cause. |
| get_endpoint_metricsC | [probe/Prometheus] Per-endpoint request rate, error rate, and latency (http.server.requests). |
| get_outbound_client_metricsB | [probe] Latency/error rate per downstream target from http.client.requests: which dependency is slow, from the caller's view. |
| get_actuator_healthB | [probe] Actuator /health with component detail (db, diskSpace, redis, custom indicators). |
| get_jvm_configA | Effective JVM flags and Spring env from the pod spec (redacted) with heap-vs-limit and GC findings; Actuator /info if a probe exists. |
| get_proxy_statusA | [probe] nginx stub_status per pod: active/reading/writing/waiting, accepts vs handled (drops). |
| summarize_access_logA | [probe] Proxy access log aggregated: status classes, top paths with p50/p95, per-upstream latency and 504s, 499s (clients giving up), proxy-vs-upstream gap, scanner-like paths, sensitive data in the log. Never raw lines. |
| get_proxy_config_summaryA | Parses the nginx config from the workload's ConfigMap: upstreams, locations, timeouts, buffering, gzip, cache headers for assets vs index.html, security headers, rate limits - with findings. |
| get_static_bundle_statsC | [probe] Served frontend build: JS/CSS/image bytes, largest files, hashed vs unhashed chunks, source maps shipped. |
| check_security_headersB | [ACTIVE] GET a URL from the hub and report missing security headers, version disclosure, cookie flags, HTTP->HTTPS redirect. Requires DIAG_ALLOW_ACTIVE_CHECKS. |
| get_web_vitalsB | [probe RUM] Core Web Vitals p75/p95 per route (LCP, INP, CLS, FCP, TTFB) with good/needs-improvement/poor ratings. |
| get_page_viewsB | [probe RUM] Most visited routes, entry routes, sessions, device split. |
| get_page_load_breakdownB | [probe RUM] Navigation Timing phases per route (dns, connect, tls, ttfb, download, domInteractive, DCL, load) with a diagnosis of where full-page loads spend time. |
| get_browser_api_latencyB | [probe RUM] Browser-observed latency per API endpoint and slowest assets; compare with service-side and proxy-side numbers to localize slowness. |
| get_frontend_errorsB | [probe RUM] JavaScript errors grouped by signature with counts, first/last seen, routes. |
| security_postureA | Static security findings with severity for workloads: privileged/root/host namespaces/capabilities/seccomp/rootfs, secrets in env, unpinned images, no limits, SA token automount, missing NetworkPolicy, over-privileged RBAC. No Secret contents are read. |
| get_exposureA | What is reachable from outside: LoadBalancer/NodePort Services, Ingress routes (TLS or not), hostNetwork pods, management paths exposed. |
| get_rbac_for_workloadA | Effective RBAC of the workload's ServiceAccount, with an over-privilege verdict. |
| get_secret_usageB | Which Secrets are referenced by which workloads and how (env vs volume). Names/keys only, never values. |
| get_tls_statusC | Ingress TLS coverage; with host (+port) and active checks enabled, performs a TLS handshake and reports expiry, issuer, protocol, chain trust. |
| scan_logs_for_sensitive_dataA | Scans recent logs for PII (emails, cards with Luhn, SSNs, phones) and secrets (JWTs, cloud keys, Bearer/Basic, connection strings, PEM). Returns counts and masked samples only. |
| get_egress_destinationsB | [probe] Where a pod currently talks to, classified (cluster service/pod, private, PUBLIC INTERNET, cloud metadata). Exfil and unexpected-dependency signal. |
| get_image_inventoryB | Images, registries, tags, running digests per workload with unpinned/latest/moved-tag findings. Input for a CVE scanner. |
| diagnose_serviceA | RUNBOOK: status -> events -> resources/throttling -> OOM/crash -> endpoints -> JVM/pool/downstreams -> log errors -> golden signals -> recent changes. Returns ranked hypotheses with evidence and the next tool to run. Start here for 'why is X broken/slow?'. |
| diagnose_slow_requestsA | RUNBOOK for latency: per-endpoint latency, throttling, GC, connection pool, thread pool/locks, downstreams, proxy timeouts (pass proxy_service for the user-facing view). |
| diagnose_slow_pageB | RUNBOOK for a slow frontend route: vitals -> TTFB vs render split -> bundle/caching -> browser API latency -> service metrics. Pass proxy_service (nginx workload) and api_service. |
| health_reportA | RUNBOOK 'Monday morning' digest for a namespace: unhealthy pods, restarts, warnings, resource pressure, HPA at max, node pressure, endpoint problems, missing NetworkPolicies, security findings, TLS gaps, with suggested actions. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 57 tools
Most tools have detailed, distinct descriptions, but the large surface creates several near-overlaps: get_endpoints vs get_endpoint_metrics, get_exposure vs get_ingress_routes, get_open_connections vs get_egress_destinations, and get_web_vitals vs get_page_load_breakdown. An agent could plausibly select the wrong tool without reading descriptions carefully.
The dominant pattern is get_verb_noun in snake_case, with list_, summarize_, check_, and diagnose_ used predictably for their categories. Minor outliers like health_report, security_posture, and what_changed break the verb-first convention but are still readable.
57 tools is far beyond the typical well-scoped MCP surface and will impose significant selection burden on agents. While the domain is broad, the count exceeds even the 25+ threshold for 'too many' in the calibration.
The surface covers Kubernetes diagnostics remarkably thoroughly: metrics, logs, events, traces, JVM internals, proxy behavior, RUM, network, security, config, and runbooks. Minor gaps remain around direct node inventory, Prometheus alert evaluation, and storage/PVC status, but agents can usually work around them.