Stop Memorizing kubectl: Troubleshoot and Deploy on Amazon EKS Just by Asking
A practical, security-first guide to the Amazon EKS MCP Server: what it is, how to set it up, and how to use it without losing control of your cluster.
Why it matters
It's 2 a.m. and a service is crash-looping. You open a terminal and start the usual routine:
kubectl get pods, kubectl describe, kubectl logs, then CloudWatch, then IAM, then the docs. Each step is simple, but together they eat time and focus.The Amazon EKS MCP server lets an AI assistant such as Kiro, Cursor, Cline, or your own agent do that legwork through the Model Context Protocol (MCP), working from live cluster data instead of guesses. You describe the problem in plain English. The assistant gathers evidence, explains what it found, and proposes a fix for you to approve.
What is MCP, in one minute?
MCP is an open standard that connects AI assistants to external tools and data. An MCP server exposes a set of tools, and the assistant decides when to call them based on your request. Think of it as a universal adapter between an AI model and your infrastructure. The EKS MCP server's tools cover managing EKS clusters and Kubernetes resources.
Two ways to run it
1. Open-source local server (
awslabs.eks-mcp-server). It runs on your own machine and gives you full control over authentication and configuration.2. Fully managed, hosted server (preview at the time of writing). Announced in November 2025, it runs in the AWS cloud, so there is nothing to install or maintain. It adds automatic updates and patching, IAM-based security, and audit logging through AWS CloudTrail. Clients connect through an MCP proxy that uses AWS SigV4 authentication.
| Local server | Managed server | |
|---|---|---|
| Where it runs | Your machine | AWS cloud |
| Maintenance | You update it | Automatic updates and patching |
| Authentication | Your AWS credentials or kubeconfig | AWS SigV4 through an MCP proxy |
| Audit trail | Your own logging | AWS CloudTrail |
| Best for | Experimenting, full control | Teams that want centralized security |
Check the AWS documentation for the current status of the hosted server before using it in production.
What you can do with it
- Troubleshoot: pull pod logs, Kubernetes events, and CloudWatch data, and consult an EKS troubleshooting knowledge base.
- Deploy: generate Deployment and Service manifests and apply them.
- Manage resources: list, read, and change Kubernetes resources without remembering
kubectlsyntax. - Create clusters: provision a cluster and its VPC through CloudFormation (local server, write mode).
- Plan upgrades: ask about upgrade readiness and best practices.
An example session
Here is what a typical troubleshooting conversation can look like. This is an illustrative example, not a transcript.
You: "The
checkout pods in prod keep restarting. What's going on?"Assistant (behind the scenes): lists the pods, notices a high restart count, reads the recent events and logs, and checks memory metrics.
Assistant (to you): "The containers are being killed for running out of memory. Usage reaches the 256Mi limit shortly after startup. I suggest raising the limit to 512Mi. Here is the updated manifest. Want me to apply it?"
You: "Show me the diff first."
You stay in the loop at the moment that matters: approving the change. The tedious evidence gathering is what gets automated.
Setup in five minutes (local server)
Prerequisites: Python with
uv, AWS credentials, and an EKS cluster.Add this to your MCP client's configuration, for example
~/.kiro/settings/mcp.json for Kiro or Settings → Tools & MCP in Cursor:1
2
3
4
5
6
7
8
9
10
11
12
13
{
"mcpServers": {
"awslabs.eks-mcp-server": {
"command": "uvx",
"args": ["awslabs.eks-mcp-server@latest"],
"env": {
"AWS_PROFILE": "your-profile",
"AWS_REGION": "us-east-1",
"FASTMCP_LOG_LEVEL": "ERROR"
}
}
}
}Restart your client and try: "List my EKS clusters." If the tools don't appear, restart the IDE or CLI and set
FASTMCP_LOG_LEVEL=DEBUG to see what's happening.The two flags that control risk
| Flag | What it enables |
|---|---|
--allow-write | Create, update, and delete operations |
--allow-sensitive-data-access | Access to logs, events, and secrets |
Without them, the server runs read-only. To enable them, add the flag to the
args list:1
"args": ["awslabs.eks-mcp-server@latest", "--allow-write"]Also note that in kubeconfig mode the AWS-specific tools are disabled.
A safe permissions model
- Start read-only. Grant describe and list permissions only. A minimal starting point looks like this (adapt it to your account, and add CloudWatch read permissions if you want logs and metrics):```json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"eks:DescribeCluster",
"eks:DescribeInsight",
"eks:ListInsights",
"eks-mcpserver:QueryKnowledgeBase"
],
"Resource": "*"
}
]
}``` - Remember Kubernetes access. AWS permissions alone aren't enough to read cluster resources. The IAM role also needs access inside the cluster, for example through an EKS access entry with a read-only policy.
- Use two server entries. Keep one read-only configuration for inspection and a separate one for write operations, enabled only when needed.
- Be careful with write policies. Cluster creation and deployments need broad permissions (IAM, VPC, CloudFormation, and EKS). AWS warns that combining write mode, sensitive-data access, and broad permissions grants significant privileges. Use a dedicated, scoped role.
- Test on a non-production cluster first.
- Review every change. Treat a proposed
applylike a pull request and read the YAML before approving. - Limit secrets exposure. Enable sensitive-data access only when you need logs, events, or secrets.
Prompts that work well
- "Find pods in the
prod-apinamespace that restarted in the last hour and summarize the likely cause." - "Compare memory usage to limits for the
ordersdeployment and suggest new values." - "Generate a Deployment and Service for
my-app:1.4on port 3000 with 2 replicas. Show me the YAML before applying." - "What could block an upgrade to the next Kubernetes version?"
- "Explain what this manifest does and flag anything risky."
Tip: ask the assistant to show its plan and the manifest before it applies anything. It keeps you in control and makes mistakes easy to catch.
Tips for getting better results
- Be specific. Name the cluster, namespace, and workload. "Why is
checkoutinprodfailing?" beats "Why is my app broken?" - Ask for evidence. "Which logs or events support that conclusion?" helps you verify the answer.
- Go step by step. Diagnose first, then ask for a fix, then ask it to apply it.
- Keep prod separate. Use separate AWS profiles per environment so a prompt can't hit the wrong cluster.
Common pitfalls
- Tools don't show up: restart the client and check the config path and JSON syntax.
- Access denied errors: check both the IAM permissions and the Kubernetes access for your role.
- Wrong region or cluster: confirm
AWS_REGIONandAWS_PROFILEin the config. - Write actions are blocked: that's the default. Add
--allow-writedeliberately, and only where appropriate.
Limitations
- It assists your judgment but doesn't replace Kubernetes knowledge.
- Models can misread logs or suggest wrong values, so verify before applying.
- Tools and flags evolve, so rely on the official documentation for the latest details.
Conclusion
The EKS MCP server can turn a long session of switching between tools into a single conversation. Start read-only on a test cluster, enable write access deliberately, and keep a human approving every change. If you want IAM and CloudTrail integration without running anything locally, the managed server is worth following.
Have you tried it yet? Share what worked, and what didn't, in the comments.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article