MCP field guide / AWS

// mcp field guide · infrastructure

AWS MCP servers

AWS ships a suite of ~60 MCP servers, and the honest headline is that most of them only read — docs, pricing, IaC validation, observability. Gating those is theater. But one server, the Core AWS API server, can run any AWS CLI command — including terminate-instances and delete-stack. Here's the map.

Maintainer: AWS Labs (official) Repo: awslabs/mcp (~60 servers) License: Apache-2.0

GUARD FIT · READ / ADVISORY SERVERS

PASS-THROUGH

Documentation, Pricing, Billing, IaC validation, CloudWatch/CloudTrail, retrieval, security assessment — they don't change infra. A gate here is theater.

GUARD FIT · CORE API + WRITE SERVERS

STRONG

call_aws runs any CLI (terminate, delete-stack, s3 rb); CCAPI/IAM/DB deletes compound it. One tool, unbounded blast radius.

Overall fit: STRONG for the mutating servers, weak for the read/advisory majority — this is a suite, so grade it per server.

What it is

awslabs/mcp is AWS Labs' official, first-party suite of ~60 specialized MCP servers (Apache-2.0), each installed independently. Some are purely observational; some mutate infrastructure; and the general-purpose Core server can run essentially any AWS API call. Write/mutation is typically off by default, gated behind flags like --allow-write, READ_OPERATIONS_ONLY, and REQUIRE_MUTATION_CONSENT.1

Correction to a common belief: the standalone CDK, Terraform, and Diagram servers were removed from the suite, and Cost Analysis was replaced by Pricing. Their successor, the IaC server, is advisory only — it validates, lint-checks and troubleshoots CloudFormation/CDK but has no deploy or stack-mutation tool. "The AWS CDK/Terraform MCP deploys or destroys infra" is out of date.2

Servers by risk surface

TierServers
read / advisoryDocumentation, Knowledge, IaC (validate/lint/troubleshoot — no deploy), Pricing, Billing & Cost Management, CloudWatch, CloudTrail, Prometheus, Well-Architected Security, retrieval (Bedrock KB, Kendra, Q), databases in default read-only mode
mutating (flag-gated)Core AWS API (call_aws create/update), EKS, ECS, Serverless (SAM deploy), SageMaker, AppSync, DataProcessing, S3 Tables, messaging (SNS/SQS, MQ, Step Functions, Lambda invoke), write-enabled databases — most behind --allow-write
destructiveCore call_aws — any destructive CLI (ec2 terminate-instances, s3 rb/rm, rds delete-db-instance, cloudformation delete-stack); CCAPI (deprecated)4 — delete across the 1,100+ resource types supported by AWS Cloud Control API; IAM5 — delete users/keys, "force delete"; EKS/ECS cluster deletion; write-DB DROP/DELETE

The sharpest edge is the Core server's call_aws (plus suggest_aws_commands, get_execution_plan): one tool that executes arbitrary AWS CLI, guarded today only by coarse env-vars — READ_OPERATIONS_ONLY (reads only) or REQUIRE_MUTATION_CONSENT (a blanket prompt before any non-read). AWS itself warns it is not for multi-tenant use and runs with the user's full permissions.3

Real use cases

"Why did my bill jump?" Pricing + Billing + CloudWatch analyze spend and recommend savings — read-only.

IaC authoring loop. Generate a template, then validate + compliance-check + troubleshoot with the IaC server before a human deploys through normal pipelines — advisory.

Conversational ops. Core AWS API to inspect and then act ("list unencrypted buckets," then remediate) — where real mutation/deletion actually happens.

Where a human-approval guard fits

Advisory / read servers → weak. Documentation, Knowledge, IaC validation, Pricing, Billing, CloudWatch/CloudTrail, retrieval, security assessment don't change infrastructure. A transactional approval guard adds little beyond audit logging — wrapping a docs lookup in an approval gate is theater, and we'll say so.

Core API + delete-capable servers → strong. The Core server is arguably the strongest case in the whole ecosystem: one tool that can terminate instances, delete a stack, or empty a bucket, guarded only by coarse env-vars. A guard that classifies risk per underlying CLI verb, shows an impact diff, and holds destructive verbs for a human is a materially finer control than REQUIRE_MUTATION_CONSENT's blanket prompt. Same logic for CCAPI deletes, IAM force-delete/key deletion, and write-enabled DB DROP/DELETE.

Honesty, both directions: most of these deletions are genuinely irreversible (a terminated instance, a deleted RDS with no final snapshot, emptied S3 objects) — the guard's value is prevention at the gate, not "undo." And we won't overstate the danger either: the IaC server can't destroy anything, and DB/EKS/ECS destruction requires the operator to have explicitly enabled writes first. Match the control to the server.

Gate call_aws, pass the docs lookups

ChronoMCP classifies the Core server's calls by the underlying verb — holding terminate/delete for a human while reads and advisory servers flow.

Read the quickstart → More MCP profiles

Sources

  1. AWS Labs — MCP suite (repo, server catalog): github.com/awslabs/mcp · awslabs.github.io/mcp
  2. IaC server (advisory-only tool set; successor to removed CDK/Terraform servers): github.com/awslabs/mcp/tree/main/src/aws-iac-mcp-server
  3. Core AWS API server (call_aws, READ_OPERATIONS_ONLY/REQUIRE_MUTATION_CONSENT, multi-tenant warning): github.com/awslabs/mcp/tree/main/src/aws-api-mcp-server
  4. CCAPI server (deprecated; Cloud Control API delete surface — 1,100+ supported resource types): github.com/awslabs/mcp/tree/main/src/ccapi-mcp-server
  5. IAM server (delete_user with force, delete_access_key, delete_group): github.com/awslabs/mcp/tree/main/src/iam-mcp-server

Profiles describe third-party software from its public sources; ChronoMCP is not affiliated with AWS. The suite changes weekly (servers added/deprecated/removed); the ~60 count and some per-tool names are point-in-time and marked accordingly. Risk groupings are our classification. Capabilities reflect sources current as of Aug 2026 — check the source links for the latest.