Using the AKS-MCP Server in Day-to-Day Operations

Azure Kubernetes Service (AKS) has long been the leading platform for containerized workloads on Microsoft Azure. While AKS offers scalability and resilience, managing it day-to-day still involves switching between various tools: Azure CLI, kubectl, ARM templates, and portal dashboards.

This is where the Microsoft AKS-MCP Server, part of the Model Context Protocol (MCP) ecosystem, makes a difference. By providing a structured, secure interface for agents and tools to perform Azure and Kubernetes actions, AKS-MCP changes how engineers interact with clusters.

It acts as a bridge between AI agents and operational activities, enabling conversational, secure, and auditable control over AKS resources.

This article covers installing and configuring the Microsoft AKS-MCP Server, validating it using live code examples, and demonstrating real operational use cases. We focus on practical engineering insights rather than marketing hype, providing an expert, reflective perspective on how it integrates with your existing DevOps and platform workflows.

The Case for MCP in Kubernetes Operations

If you’ve ever wished to ask an intelligent assistant to “show me all failing pods in production” or “scale node pool np1 to five nodes,” you’re describing a perfect scenario for the Model Context Protocol.

MCP provides a standardized method for external agents, such as AI models or ChatOps bots, to access functions and tools with structured, permissioned access. Microsoft’s implementation extends this protocol to Azure services, specifically now to AKS. Instead of giving an AI system shell access or open API tokens, you can set up an MCP Server that only exposes the specific capabilities you choose, such as listing clusters, applying manifests, retrieving pod logs, or scaling node pools.

For DevOps or platform engineers, this allows automation of insights, empowerment of internal bots, or enhancement of developer platforms, all while maintaining control and compliance. The AKS-MCP Architecture

AKS-MCP is essentially a middleware that connects your intelligent clients to your Azure environment. It leverages the Azure SDK’s DefaultAzureCredential, enabling authentication through existing credentials or Managed Identities, and securely interacts with both Azure Resource Manager and the Kubernetes API.

 

When a user or agent issues a natural-language command like “List node pools in my production cluster,” the process unfolds as follows:

The agent interprets the intent and constructs a call based on the MCP specification.
This call is sent through supported transports such as stdio or HTTP.
The AKS-MCP Server processes the call and uses the Azure and Kubernetes SDKs to execute the request.
The results are returned as structured JSON to the agent for visualization or additional analysis.

This architectural separation establishes clear boundaries: the agent never directly accesses your cluster, credentials stay within Azure’s identity system, and all operations can be logged and audited.

Deploying the Microsoft AKS-MCP Server

The AKS-MCP Server can be deployed in various ways: locally for testing, containerized within a management cluster, or hosted through Azure Container Apps. Below is an example of an installation pattern suitable for production deployments.

Prerequisites

You’ll need:
• An active Azure subscription
• One or more AKS clusters
• Azure CLI, Helm, and kubectl installed
• A service principal or Managed Identity with Contributor or AKS Cluster Admin roles
• Network egress from the MCP pod to Azure APIs and your AKS API server

Step 1: Obtain the Source and Container Image

Clone the official repository:

git clone https://github.com/Azure/aks-mcp.git
cd aks-mcp

You can either build your own image or use the one published by Microsoft:

docker build -t myregistry.azurecr.io/aks-mcp:latest .
docker push myregistry.azurecr.io/aks-mcp:latest</code/pre>

Alternatively, deploy direct from GitHub Container Registry:

helm repo add aks-mcp https://raw.githubusercontent.com/Azure/aks-mcp/main/chart/

Step 2: Create an Azure Service Principal (optional)

If you prefer explicit credentials over Managed Identity, create a service principal.

az ad app create --display-name aks-mcp-server
az ad app credential reset --id <appId> --credential-description "mcp" --years 2
az role assignment create --assignee <appId> --role Contributor --scope /subscriptions/<subscriptionId>

Storing the generated credentials as a Kubernetes Secret:

apiVersion: v1
kind: Secret
metadata:
name: azure-credentials
namespace: mcp
type: Opaque
stringData:
tenantId: "<tenantId>"
clientId: "<appId>"
clientSecret: "<password>"
subscriptionId: "<subscriptionId>"

Step 3: Deploy via Helm

helm install aks-mcp aks-mcp/aks-mcp --namespace mcp --create-namespace \ --set image.repository=myregistry.azurecr.io/aks-mcp \ --set image.tag=latest \ --set env.azureTenantIdSecretName=azure-credentials \ --set env.azureClientIdSecretName=azure-credentials \ --set env.azureClientSecretSecretName=azure-credentials \ --set env.azureSubscriptionIdSecretName=azure-credentials

Once deployed, verify:

kubectl get pods -n mcp
kubectl logs -n mcp deployment/aks-mcp

You should see log output confirming startup and readiness.

Step 4: Connecting a Client

Clients such as GitHub Copilot Agents or custom applications connect through MCP configuration files.

Example .mcp.json:

{
"mcpServers": {
"aks-mcp": {
"type": "stdio",
"command": "/usr/local/bin/aks-mcp",
"args": ["--transport=stdio"]
}
}
}
For HTTP exposure:

{
"mcpServers": {
"aks-mcp": {
"url": "https://aks-mcp.mycompany.com",
"type": "http"
}
}
}

Test Connectivity:

kubectl port-forward svc/aks-mcp 8080:8080 -n mcp

Then run a local MCP client to send test requests.

Using AKS-MCP in Real Operations

Once installed, the AKS-MCP Server seamlessly integrates into your daily operations. It’s more than just experimental technology; it acts as a productivity layer that enhances observability, remediation, and governance right where engineers work and make decisions.

Diagnostics and Cluster Insight

Imagine a ChatOps scenario:

“Show me all AKS clusters in my subscription, then list pods in namespace payments that are not ready.”

The agent issues a sequence of MCP calls:

from azure.mcp.client import MCPClient

client = MCPClient(server_address="http://localhost:8080")
clusters = client.invoke("aks.getClusters")
pods = client.invoke("aks.getPods", {"cluster": "prod-aks", "namespace": "payments"})
print(pods)

The response is provided in JSON format, which your bot or console can then display as human-readable text.

Scaling and Resource Management
For autoscaling or temporary scaling, instead of manually executing az aks nodepool scale, the agent can use the following command:

res = client.invoke("aks.scaleNodePool", {
"cluster": "prod-aks",
"resourceGroup": "rg-prod",
"nodePool": "np1",
"newCount": 5
})/

The AKS-MCP Server translates this into ARM API calls and returns confirmation.

Rolling Deployments via Conversational Commands

A natural conversation with an internal assistant might look like:

“Deploy version v2.1.0 of orders-api to staging and verify rollout success.”

The agent decomposes this into steps:
1. Apply the manifest
2. Monitor rollout status
3. Fetch logs for failed pods

client.invoke("aks.applyManifest", {
"cluster": "stg-aks",
"namespace": "orders",
"manifest": open("orders-api-v2.1.0.yaml").read()
})
status = client.invoke("aks.getRolloutStatus", {
"cluster": "stg-aks",
"namespace": "orders",
"deployment": "orders-api"
})

If the rollout fails, it calls getPodLogs automatically.

The engineer gets a narrative response instead of raw log output, such as:

“Two pods in orders-api failed to start. Container api shows CrashLoopBackOff due to image pull error.”

That’s actionable intelligence instead of static output.

Governance and Security Reviews

Since AKS-MCP exposes controlled functions, it can be securely integrated with internal governance bots.

A compliance bot could ask:

“List all cluster roles that allow delete privileges.”

The server queries the Kubernetes API and returns results, enabling the bot to suggest solutions. In hybrid environments, combine AKS-MCP with the general Azure MCP server to cross-check resource roles at both the Azure RBAC and Kubernetes RBAC levels.

Integrating into Platform Engineering Workflows

For platform teams creating self-service portals or internal developer platforms (IDPs), AKS-MCP can serve as the core of conversational automation. Instead of revealing raw pipelines, developers can request infrastructure changes in simple English, with the MCP layer ensuring policy compliance and identity verification.

This approach integrates well with GitOps workflows, as MCP can initiate pull requests or run kubectl apply commands under supervision, connecting human intent with automated deployment.

Operational Security Considerations

AKS-MCP functions within your trusted Azure identity boundary, but it can still execute commands that change resources. To ensure security:
• Always use Managed Identity for authentication.
• Reduce network exposure by placing AKS-MCP in a private subnet or using internal ingress only.
• Track API activity and MCP requests in Log Analytics.
• Apply request throttling and validate inputs.
• Enforce role segregation with readonly, readwrite, and admin tiers.
• Keep comprehensive logs of all actions, detailing who or what performed them.

These measures align with Zero Trust principles and preserve traceability.

Example: End-to-End Workflow in Action
Here’s an example conversation an internal AI assistant might manage:
1. Engineer: “Increase the payments node pool in production to six nodes.”
2. MCP Client: Interprets the intent and constructs a scaleNodePool request.
3. AKS-MCP Server: Checks permissions, then calls Azure ARM to execute the scaling.
4. Result: Receives structured JSON indicating “Scale operation succeeded.”

Shortly after, the same assistant can verify:

“List node counts and running pods in production.”

MCP calls getNodePools → getPods → aggregates → responds with counts.

This combination of agent reasoning and MCP enforcement provides teams with conversational control while maintaining governance.

Where AKS-MCP Fits in the Broader Azure Ecosystem

AKS-MCP does not replace your CI/CD pipelines, Infrastructure as Code (IaC) templates, or monitoring systems; instead, it complements them. Think of it as a new operational interface that enables intent-based, just-in-time actions without bypassing existing policies.

For example:
• Terraform or Bicep remain your declarative configuration tools.
• Pipelines continue to perform standard deployments.
• MCP servers manage ad-hoc operations, diagnostics, or self-service requests, all logged, identity-aware, and reversible.

The integration of MCP and AI assistants is poised to transform DevOps tools. By 2026, most enterprise clouds will likely have internal copilots relying on MCP connectors like this one.

Observability and Auditing

Each call handled by AKS-MCP can generate telemetry data. By sending logs to Azure Monitor or a centralized Log Analytics workspace, you obtain:
• Complete audit records of AI-driven actions
• Metrics on invocation frequency
• Insights into latency and error rates
• Custom dashboards that connect AI agent activity with cluster operations

A recommended method is to tag all AKS-MCP pods with env=operations and export logs using ContainerInsights. You can then analyze usage patterns through Kusto queries, for example:

# Kusto query
ContainerLog
| where Name == "aks-mcp"
| project TimeGenerated, LogEntry, Computer
| sort by TimeGenerated desc

That provides immediate visibility into how your AI agents interact with your clusters.

Future Directions

The current AKS-MCP Server already supports most essential AKS and Kubernetes functions, but upcoming versions are expected to feature:
• Integration with Azure Policy for real-time enforcement
• Built-in workload validation (similar to OPA or Gatekeeper)
• Event-driven triggers for scaling and failover
• A secure plugin architecture for custom tools

As it develops, broader adoption is likely in regulated industries requiring conversational automation with strict controls.

References

• Microsoft Learn: Get Started with Azure MCP Server
• GitHub: Azure/aks-mcp
• Blog: Announcing the AKS-MCP Server
• TechCommunity: Deploying MCP Server Using Azure Container Apps
• Medium: Automating Troubleshooting with Azure MCP

Conclusion

The Microsoft AKS-MCP Server marks a subtle yet significant shift in managing Kubernetes on Azure. It doesn’t aim to replace engineers but to enhance their intentions by ensuring every command passes through an intelligent, policy-aware layer.

From cluster scaling to rollout diagnostics, MCP makes the cloud more conversational, contextual, and compliant. In daily operations, it’s the difference between just finding the correct command and achieving the desired outcome.

For platform engineers and architects, this signals the start of a new phase: orchestrating not only containers but also context.