Amazon EKS

Amazon's EKS MCP server reads Kubernetes resources, pod logs and events, CloudWatch logs and metrics, and EKS insights, and searches the EKS troubleshooting guide. It signs in with AWS IAM, so its access is whatever its IAM role allows.

There are two ways to run it. Both sit behind Supergateway, which turns them into a Streamable HTTP endpoint with an API key.

For plain Kubernetes reads without AWS extras, the Kubernetes server also works on EKS.

1. Create a read-only IAM roleCopy Anchor Link

Create an IAM role for the proxy or server, assumable where it will run (EKS Pod Identity, IRSA, or an ECS task role).

• AWS-hosted server: attach the managed policy AmazonEKSMCPReadOnlyAccess. It allows starting the server and calling its read-only tools. Write tools need eks-mcp:CallPrivilegedTool, which this policy doesn't grant.
• Open-source server: attach a policy with the read actions it needs: eks:DescribeCluster, eks:DescribeInsight, eks:ListInsights, ec2:DescribeVpcs, ec2:DescribeSubnets, ec2:DescribeRouteTables, cloudformation:DescribeStacks, cloudwatch:GetMetricData, logs:StartQuery, logs:GetQueryResults, eks-mcpserver:QueryKnowledgeBase, and for its IAM tools iam:GetRole, iam:GetRolePolicy, iam:ListRolePolicies, iam:ListAttachedRolePolicies, iam:GetPolicy and iam:GetPolicyVersion.

2. Let the role read the clusterCopy Anchor Link

Kubernetes reads (pods, logs, events) go through the cluster's own access control. Give the role an EKS access entry with the read-only AmazonEKSViewPolicy, which can't read Secrets:

ROLE=arn:aws:iam::123456789012:role/sremcp-eks-mcp
aws eks create-access-entry --cluster-name prod --principal-arn "$ROLE"
aws eks associate-access-policy --cluster-name prod --principal-arn "$ROLE" \
  --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSViewPolicy \
  --access-scope type=cluster

3. Run it behind SupergatewayCopy Anchor Link

Run one of these with the role's credentials: as a pod using the role through EKS Pod Identity or IRSA, as an ECS task with the role, or elsewhere with AWS_* credential variables. The examples use Docker for brevity. The supergateway:uvx image includes uv.

docker run -d -p 8000:8000 -e AWS_REGION=us-east-1 \
  -e SUPERGATEWAY_API_KEY="$MCP_API_KEY" \
  supercorp/supergateway:uvx \
  --stdio "uvx mcp-proxy-for-aws@latest https://eks-mcp.us-east-1.api.aws/mcp --service eks-mcp --region us-east-1" \
  --outputTransport streamableHttp --port 8000

Then expose it over https. See Expose a self-hosted server.

4. Onboard in sremcpCopy Anchor Link

5. Approve toolsCopy Anchor Link

Read tools, for example: list_k8s_resources, get_pod_logs, get_k8s_events, get_cloudwatch_logs, get_cloudwatch_metrics, get_eks_insights, get_eks_vpc_config, search_eks_troubleshoot_guide.

Don't approve manage_k8s_resource, apply_yaml, generate_app_manifest, manage_eks_stacks or add_inline_policy. With sensitive-data access on, manage_k8s_resource can also read Secrets where the cluster allows it.

Try itCopy Anchor Link

• Are there any EKS insights or upgrade blockers on the prod cluster?
• Why are pods in the orders namespace pending? Check events and node capacity.
• Show CloudWatch error logs for the payments service in the last hour.