AWS (AWS Labs) for cloud infrastructure
Most teams that run on a cloud run on AWS, and that is exactly why the AWS Labs server is the top pick of four for managing cloud infrastructure from an agent. It does not wrap a curated set of resource types behind bespoke tools. It hands the agent the AWS CLI, the same surface you already use, with validation and a read-only mode wrapped around it.
That design is what earns it first place here: anything the CLI can reach (EC2, S3, VPC, RDS, IAM, and the rest) the agent can inspect or operate through one tool. The breadth that makes it the default for AWS shops is also its honest limit, since it assumes you actually live on AWS rather than Google Cloud or Azure.
How AWS (AWS Labs) fits
Three tools do the work. call_aws executes one or more CLI commands when the agent already knows the exact invocation, which is the common path for listing instances, describing a security group, or reading a stack's status. suggest_aws_commands turns a vague request ("why can this Lambda not reach the database") into candidate commands when the precise call is uncertain. get_execution_plan, an experimental tool behind a flag, sketches a step-by-step workflow for a multi-stage task. Run it in read-only mode and the agent can diagnose freely without changing anything live.
The limit is scope: this server is AWS and only AWS. If your resources sit in Google Cloud, Google Cloud Run fits better; for a Microsoft estate, Azure is the match. Cloudflare is the pick for the edge layer (DNS, Workers, R2) that often sits in front of an AWS backend rather than inside it. On AWS itself, none of the three siblings competes with running the full CLI through one validated tool.
Tools you would use
| Tool | What it does |
|---|---|
| call_aws | Execute one or more AWS CLI commands with validation and error handling. The primary tool when the exact command is known. |
| suggest_aws_commands | Suggest AWS CLI commands from a natural-language description. A fallback for when the exact command is uncertain. |
| get_execution_plan | Produce a step-by-step agent-script workflow for a complex AWS task (experimental, enabled via a flag). |
FAQ
- Does the AWS MCP server cover every AWS service?
- Effectively yes, because call_aws runs the AWS CLI, and whatever the CLI can reach the agent can reach. There are no per-service tools to wait on: if the command exists, the agent can run it through this one server.
- Can I stop the agent from changing my infrastructure?
- Yes. The server supports a read-only mode, so the agent can describe and diagnose resources without executing mutating commands. Pair that with suggest_aws_commands when you want it to propose a fix you then approve.