InfraClaude
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| KUBECONFIG | No | Path to the Kubernetes configuration file (e.g., ~/.kube/config). | |
| PROMETHEUS_URL | No | The URL of the Prometheus server (e.g., http://localhost:9090). |
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 | {} |
| prompts | {} |
| resources | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| k8s_get_podsB | List pods in a Kubernetes namespace with their status, restarts, and age |
| k8s_describe_podB | Get detailed information about a specific pod including containers, resources, and events |
| k8s_delete_podA | Delete a specific pod (it will be recreated if managed by a controller) |
| k8s_get_pod_logsC | Fetch logs from a pod with options for tail lines, time range, and container selection |
| k8s_get_eventsC | List cluster events filtered by namespace and type (Normal/Warning) |
| k8s_top_podsA | Show CPU and memory usage for pods (requires metrics-server) |
| k8s_top_nodesA | Show CPU and memory usage for all cluster nodes (requires metrics-server) |
| k8s_get_deploymentsB | List deployments with replica status, strategy, and age |
| k8s_rollout_statusC | Check the rollout status of a deployment |
| k8s_rollback_deploymentC | Rollback a deployment to the previous revision |
| k8s_scale_deploymentC | Scale a deployment to a specified number of replicas |
| k8s_get_servicesB | List services with type, cluster IP, ports, and age |
| k8s_get_nodesA | List all cluster nodes with status, roles, and version |
| k8s_describe_nodeB | Get detailed node info including capacity, allocatable resources, conditions, and taints |
| k8s_cordon_nodeA | Mark a node as unschedulable (cordon) — prevents new pods from being scheduled |
| k8s_uncordon_nodeA | Mark a node as schedulable (uncordon) — re-enables pod scheduling |
| docker_list_containersB | List Docker containers with their status, image, and ports |
| docker_inspect_containerC | Get detailed information about a Docker container |
| docker_container_logsC | Fetch logs from a Docker container |
| docker_container_statsC | Get real-time CPU, memory, and network stats for a container |
| docker_list_imagesB | List local Docker images with repository, tag, and size |
| docker_inspect_imageC | Get detailed information about a Docker image |
| docker_compose_psC | Show status of Docker Compose services |
| docker_compose_logsB | Show logs from Docker Compose services |
| docker_list_networksB | List Docker networks with driver and scope |
| docker_inspect_networkA | Get detailed info about a Docker network including connected containers |
| prom_instant_queryC | Execute a PromQL instant query and return current values |
| prom_range_queryB | Execute a PromQL query over a time range and return series data |
| prom_active_alertsA | List all currently firing Prometheus alerts |
| prom_alert_rulesA | List all Prometheus alert rules and their current state |
| prom_targetsB | Show Prometheus scrape target health status |
| terraform_planA | Run terraform plan to preview infrastructure changes (read-only, safe) |
| terraform_state_listB | List all resources in the Terraform state |
| terraform_state_showB | Show details of a specific resource in Terraform state |
| terraform_outputB | Read Terraform output values |
| terraform_validateC | Validate Terraform configuration and check formatting |
| security_trivy_scanC | Scan a container image for vulnerabilities using Trivy |
| security_gitleaks_scanC | Scan a directory for leaked secrets and credentials using Gitleaks |
| security_k8s_auditB | Audit Kubernetes namespace for security misconfigurations (privileged containers, missing limits, RBAC issues) |
| system_disk_usageC | Show disk usage for the system or a specific path |
| system_processesC | List top processes sorted by CPU or memory usage |
| system_network_connectionsC | Show active network connections and listening ports |
| system_logsC | Read system logs from journalctl or a log file |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| troubleshoot | Systematic troubleshooting workflow for infrastructure issues — guides you through gathering context, identifying anomalies, and suggesting fixes |
| capacity-plan | Capacity planning analysis — assess current resource usage, identify bottlenecks, and recommend scaling |
| security-audit | Infrastructure security review — check for common security misconfigurations and vulnerabilities |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| Kubernetes Cluster Info | Current cluster overview: context, nodes, namespaces, running pods count |
| Service Health Status | Health status of all services with endpoint readiness and deployment status |
| Infrastructure Summary | Full infrastructure summary: K8s cluster, Docker, Prometheus status |
TDQS
Scored across 43 tools
Most tools have distinct purposes with clear boundaries between domains (Docker, Kubernetes, Prometheus, Security, System, Terraform). However, there is some overlap between docker_compose_logs and docker_container_logs, and between k8s_get_pods and k8s_describe_pod, which could cause minor confusion. Overall, the descriptions help clarify differences, but the sheer number of tools increases cognitive load.
Tool names follow a highly consistent snake_case pattern with clear domain prefixes (docker_, k8s_, prom_, security_, system_, terraform_) and descriptive verb_noun combinations. This predictable structure makes it easy to understand each tool's purpose and domain at a glance, with no deviations in naming conventions.
With 43 tools, this server feels overloaded for a single MCP server. While the tools cover multiple infrastructure domains, the count is excessive and will overwhelm agents. A more focused approach with separate servers for Docker, Kubernetes, monitoring, etc., would be more appropriate. The scope is too broad for effective tool selection.
Within each domain, the tool coverage is quite comprehensive. Docker has inspection, listing, and monitoring tools; Kubernetes covers pod management, scaling, rollouts, and monitoring; Prometheus includes queries and alerts; Security has scanning tools; System provides diagnostics; and Terraform covers state and planning. Minor gaps exist (e.g., no Docker container creation/management, no Kubernetes pod creation), but agents can work around these given the broad coverage.