The consolidated-tool design is the right call for a surface this large — one az_aks_operations definition instead of twenty, so the tool list stays affordable. The part worth reading properly is the trust boundary section, which is unusually direct: this executes az, kubectl and helm with your credentials, supports stdio only by design, and --access-level is described as a guardrail rather than a security boundary. Run it read-only unless the session genuinely needs to change the cluster.
Microsoft's MCP server for Azure Kubernetes Service. Rather than one tool per operation, it consolidates into a handful of tools that take an operation name — so a whole area of AKS work is one tool definition. It is explicitly designed to run as a local subprocess for a single trusted user, over stdio only.
- az_aks_operations — cluster lifecycle in one tool: show, list, get-versions, create, delete, scale, start, stop, update, upgrade, check-network, get-credentials, and the nodepool operations nodepool-list, nodepool-show, nodepool-add, nodepool-delete, nodepool-scale and nodepool-upgrade
- kubectl_resources, kubectl_workloads, kubectl_cluster, kubectl_diagnostics, kubectl_metadata and kubectl_config — the kubectl surface, grouped by what you are doing rather than by verb
- aks_network_resources — the networking around a cluster: vnet, subnet, nsg, route_table, load_balancer and private_endpoint, or all of them at once
- aks_monitoring — metrics, resource_health events, app_insights KQL queries, diagnostics settings, and control_plane_logs with safety constraints
- aks_detector and aks_advisor_recommendation — Azure's own diagnostics and recommendations for the cluster
- get_aks_vmss_info and node-level log collection: kubelet, containerd, kernel or syslog from a specific VMSS instance, filtered by level, keyword or time range
- az_compute_operations for the VMs and scale sets underneath — show, list, get-instance-view, start, stop, restart and reimage
- az_fleet for multi-cluster work, and az_cli as the escape hatch when no consolidated tool covers what you need
- --access-level takes readonly, readwrite or admin, which decides which operations are registered at all
Azure CLI installed and authenticated — the server shells out to az, kubectl and helm, so those tools' own credentials are what it uses. Login is attempted in order: service principal when AZURE_CLIENT_ID, AZURE_CLIENT_SECRET and AZURE_TENANT_ID are set; workload identity when AZURE_FEDERATED_TOKEN_FILE is present; user-assigned managed identity with AZURE_CLIENT_ID alone; system-assigned when AZURE_MANAGED_IDENTITY is system. AZURE_SUBSCRIPTION_ID sets the active subscription. Installed as a binary, through the AKS VS Code extension, or built from source. Read the trust boundary section before deploying: stdio only, launched as a local subprocess, and the project states plainly that --access-level reduces the surface but is not a security boundary against a client that can already run commands.
One command — mkdir -p .vscode && curl -sL https://github.com/Azure/aks-mcp/releases/latest/download/aks-mcp-linux-amd64 -o aks-mcp && chmod +x aks-mcp && echo '{"servers":{"aks-mcp-server":{"type":"stdio","command":"'$PWD'/aks-mcp","args":[]}}}' > .vscode/mcp.json