Skip to main content
MCP Servers & Tools  /  AWS

AWS (10 MCP-Servers | 171 tools)

Give an agent read access to your AWS accounts. Updated 2026-09-13

Each capability below carries the question it answers, the prompt to paste, and setup for a single account or a landing zone.

Your AI agents & AWS MCP Servers

Your AI agents
171 tools connected
Cost & Operations
Cost & Operations
69 tools connected
Developer Tools
40 tools connected
Infra & Deployment
36 tools connected · 25 available
Data & Analytics
6 tools connected · 24 available
Integration & Messaging
22 tools connected · 6 available
Step 1 of 5
Cost & Operations
See your spend, alarms, and who changed what.
AWS Billing and Cost Management MCP Server
See where your AWS spend went, what changed, and what was unexpected — before the invoice arrives.
Connected · 45 tools
Amazon CloudWatch MCP Server
Know which alarms are firing right now and what changed just before each one went off.
Connected · 19 tools
AWS CloudTrail MCP Server
Find out who made privileged changes in your AWS accounts and exactly what they did.
Connected · 5 tools

Groups and servers are ordered by the business outcome they deliver. Lightly dimmed servers are available but not yet added to a product; the faintest are not connected yet — see why.

Cost & Operations

Where did our AWS spend go last month, what changed compared with the month before, and was any of it unexpected?
awslabs-billing-cost-management
45 MCP toolswired · 3 products
Analyze AWS costs, budgets, savings plans, and optimization opportunities.
Ask your agent
Show last month's AWS cost by service, compare it with the month before and list the biggest increases, then list any cost anomalies AWS detected in that period. Do not change anything.
Read-only: by_design
Set it up
One account
export AWS_BILLING_PROFILE=<your billing read-only profile>  # from ~/.aws/config; never committed
aws sso login --profile "$AWS_BILLING_PROFILE"
aws sts get-caller-identity --profile "$AWS_BILLING_PROFILE" --output json   # confirm the account is the one you intend
add the awslabs-billing-cost-management entry to your project's .mcp.json by running: python3 .claude/mcps/scripts/derive-mcp-profile.py --all-targets
Confirm it works:
aws ce get-cost-and-usage --profile "$AWS_BILLING_PROFILE" --time-period Start=<YYYY-MM-01>,End=<YYYY-MM-DD> --granularity MONTHLY --metrics UnblendedCost --output json   # AWS bills each Cost Explorer API request
Landing zone (many accounts)
Find the accounts first:
aws organizations list-accounts --profile "$AWS_MANAGEMENT_PROFILE" --query 'Accounts[?Status==`ACTIVE`].[Id,Name]' --output text
export AWS_BILLING_PROFILE=<your payer-account billing read-only profile>
export AWS_MANAGEMENT_PROFILE=<your org management read-only profile>
run the account_discovery command to list ACTIVE accounts, so every linked account in the cost results can be matched to a name
run the landing-zone verify; an ACTIVE account missing from the results has had no spend in the period, or the profile is not the payer account -- re-check with sts get-caller-identity before concluding
Not needed for cost: Cost Explorer in the organization's payer account already returns spend for every linked account. Point AWS_BILLING_PROFILE at the payer account and group by linked account instead of switching profiles per account.
Confirm it works:
aws ce get-cost-and-usage --profile "$AWS_BILLING_PROFILE" --time-period Start=<YYYY-MM-01>,End=<YYYY-MM-DD> --granularity MONTHLY --metrics UnblendedCost --group-by Type=DIMENSION,Key=LINKED_ACCOUNT --output json
Who made privileged API calls recently, and what exactly did they do?
awslabs-cloudtrail
5 MCP toolswired · 2 products
Look up CloudTrail events and query CloudTrail Lake for privileged-API audit trail and compliance review.
Ask your agent
Look up the most recent CloudTrail events for privileged actions (create, delete, put, policy changes) and summarise who performed each one and when.
Read-only: by_design
Set it up
One account
export AWS_OPERATIONS_PROFILE=<your read-only profile>  # from ~/.aws/config; never committed
aws sso login --profile "$AWS_OPERATIONS_PROFILE"
aws sts get-caller-identity --profile "$AWS_OPERATIONS_PROFILE" --output json   # confirm the account is the one you intend
add the awslabs-cloudtrail entry to your project's .mcp.json by running: python3 .claude/mcps/scripts/derive-mcp-profile.py --all-targets
Confirm it works:
aws cloudtrail describe-trails --profile "$AWS_OPERATIONS_PROFILE" --region "$AWS_REGION" --query 'length(trailList)' --output text
Landing zone (many accounts)
Find the accounts first:
aws organizations list-accounts --profile "$AWS_MANAGEMENT_PROFILE" --query 'Accounts[?Status==`ACTIVE`].[Id,Name]' --output text
export AWS_MANAGEMENT_PROFILE=<your org management read-only profile>
run the account_discovery command to enumerate ACTIVE accounts
for each account, resolve its profile from ~/.aws/config and export AWS_OPERATIONS_PROFILE to it
repeat the single-account verify per account; a 0 result is a routing suspect, not a clean account -- re-check with sts get-caller-identity before concluding
Map each returned account id to its profile name from your own ~/.aws/config (sso_account_id -> profile). Never hardcode the mapping; it differs per operator and per tenant.
Confirm it works:
aws sts get-caller-identity --profile "$AWS_OPERATIONS_PROFILE" --output json | jq -r .Account   # must equal the account you resolved the profile for
Which CloudWatch alarms are in ALARM state right now, and what changed just before each one fired?
awslabs-cloudwatch
19 MCP toolswired · 2 products
Query CloudWatch Logs Insights, metrics, and alarms for live observability and incident triage.
Ask your agent
List every CloudWatch alarm currently in ALARM state, then show the recent alarm-history transitions for each one so I can see what changed just before it fired.
Read-only: by_design
Set it up
One account
export AWS_OPERATIONS_PROFILE=<your read-only profile>  # from ~/.aws/config; never committed
aws sso login --profile "$AWS_OPERATIONS_PROFILE"
aws sts get-caller-identity --profile "$AWS_OPERATIONS_PROFILE" --output json   # confirm the account is the one you intend
add the awslabs-cloudwatch entry to your project's .mcp.json by running: python3 .claude/mcps/scripts/derive-mcp-profile.py --all-targets
Confirm it works:
aws cloudwatch describe-alarms --profile "$AWS_OPERATIONS_PROFILE" --region "$AWS_REGION" --query 'length(MetricAlarms)' --output text
Landing zone (many accounts)
Find the accounts first:
aws organizations list-accounts --profile "$AWS_MANAGEMENT_PROFILE" --query 'Accounts[?Status==`ACTIVE`].[Id,Name]' --output text
export AWS_MANAGEMENT_PROFILE=<your org management read-only profile>
run the account_discovery command to enumerate ACTIVE accounts
for each account, resolve its profile from ~/.aws/config and export AWS_OPERATIONS_PROFILE to it
repeat the single-account verify per account; a 0 result is a routing suspect, not a clean account -- re-check with sts get-caller-identity before concluding
Map each returned account id to its profile name from your own ~/.aws/config (sso_account_id -> profile). Never hardcode the mapping; it differs per operator and per tenant.
Confirm it works:
aws sts get-caller-identity --profile "$AWS_OPERATIONS_PROFILE" --output json | jq -r .Account   # must equal the account you resolved the profile for

Developer Tools

Which roles and users can reach administrative access, and where is that permission actually attached?
awslabs-iam
29 MCP toolswired · 1 product
Review IAM users, roles, groups and policies, and simulate policy evaluation for access review.
Ask your agent
List our IAM roles, users and customer-managed policies, then simulate whether a named role can perform a specific administrative action and show which attached policy grants it.
Read-only: enforced
Set it up
One account
export AWS_OPERATIONS_PROFILE=<your read-only profile>  # from ~/.aws/config; never committed
aws sso login --profile "$AWS_OPERATIONS_PROFILE"
aws sts get-caller-identity --profile "$AWS_OPERATIONS_PROFILE" --output json   # confirm the account is the one you intend
add the awslabs-iam entry to your project's .mcp.json by running: python3 .claude/mcps/scripts/derive-mcp-profile.py --all-targets
Confirm it works:
aws iam list-roles --profile "$AWS_OPERATIONS_PROFILE" --query 'length(Roles)' --output text
Landing zone (many accounts)
Find the accounts first:
aws organizations list-accounts --profile "$AWS_MANAGEMENT_PROFILE" --query 'Accounts[?Status==`ACTIVE`].[Id,Name]' --output text
export AWS_MANAGEMENT_PROFILE=<your org management read-only profile>
run the account_discovery command to enumerate ACTIVE accounts
for each account, resolve its profile from ~/.aws/config and export AWS_OPERATIONS_PROFILE to it
repeat the single-account verify per account; a 0 result is a routing suspect, not a clean account -- re-check with sts get-caller-identity before concluding
Map each returned account id to its profile name from your own ~/.aws/config (sso_account_id -> profile). Never hardcode the mapping; it differs per operator and per tenant.
Confirm it works:
aws sts get-caller-identity --profile "$AWS_OPERATIONS_PROFILE" --output json | jq -r .Account   # must equal the account you resolved the profile for
The AWS API MCP server is being retired upstream. How do we move to its successor without losing read-only access?
awslabs-api
2 MCP toolswired · 6 productsdeprecated
Call AWS APIs and discover relevant AWS commands.
Ask your agent
I use the AWS API MCP server, which AWS is retiring. Using the AWS MCP Server instead, confirm it is available in our AWS region and search the AWS documentation for how to run it read-only, then list the steps to switch over. Cite the pages you read.
Read-only: enforced

Infra & Deployment

Which of our container services are not running as many tasks as they should, and why?
awslabs-ecs
9 MCP toolswired · 3 products
Containerize applications and manage Amazon ECS services and tasks.
Ask your agent
List our ECS clusters and the services in each one, show any service whose running task count is below its desired count, and run the ECS troubleshooting checks on it to explain why. Do not change anything.
Read-only: enforced
Set it up
One account
export AWS_OPERATIONS_PROFILE=<a read-only profile for the workload account that runs your ECS clusters>  # from ~/.aws/config; never committed
aws sso login --profile "$AWS_OPERATIONS_PROFILE"
aws sts get-caller-identity --profile "$AWS_OPERATIONS_PROFILE" --output json   # confirm the account is the one you intend
add the awslabs-ecs entry to your project's .mcp.json by running: python3 .claude/mcps/scripts/derive-mcp-profile.py --all-targets
Confirm it works:
aws ecs list-clusters --profile "$AWS_OPERATIONS_PROFILE" --region "$AWS_REGION" --query 'length(clusterArns)' --output text
Landing zone (many accounts)
Find the accounts first:
aws organizations list-accounts --profile "$AWS_MANAGEMENT_PROFILE" --query 'Accounts[?Status==`ACTIVE`].[Id,Name]' --output text
export AWS_MANAGEMENT_PROFILE=<your org management read-only profile>
run the account_discovery command to enumerate ACTIVE accounts
for each account, resolve its profile from ~/.aws/config and export AWS_OPERATIONS_PROFILE to it
repeat the single-account verify per account; a 0 result is a routing suspect, not a clean account -- re-check with sts get-caller-identity before concluding
Map each returned account id to its profile name from your own ~/.aws/config (sso_account_id -> profile). Never hardcode the mapping; it differs per operator and per tenant.
Confirm it works:
aws sts get-caller-identity --profile "$AWS_OPERATIONS_PROFILE" --output json | jq -r .Account   # must equal the account you resolved the profile for
Why did this CloudFormation deployment fail, and will the corrected template pass our security rules before we try again?
awslabs-iac
9 MCP toolswired · 4 products
Validate, troubleshoot and research CloudFormation and CDK infrastructure as code (no create/update/delete tools).
Ask your agent
Look at the failed CloudFormation stack I name and explain the root cause from its stack events and the related API calls. Then validate my corrected template and check it against security and compliance rules before I redeploy. Do not deploy anything.
Read-only: by_design
Set it up
One account
export AWS_OPERATIONS_PROFILE=<your read-only profile>  # from ~/.aws/config; never committed
aws sso login --profile "$AWS_OPERATIONS_PROFILE"
aws sts get-caller-identity --profile "$AWS_OPERATIONS_PROFILE" --output json   # confirm the account is the one you intend
add the awslabs-iac entry to your project's .mcp.json by running: python3 .claude/mcps/scripts/derive-mcp-profile.py --all-targets
Confirm it works:
aws cloudformation describe-stacks --profile "$AWS_OPERATIONS_PROFILE" --region "$AWS_REGION" --query 'length(Stacks)' --output text
Landing zone (many accounts)
Find the accounts first:
aws organizations list-accounts --profile "$AWS_MANAGEMENT_PROFILE" --query 'Accounts[?Status==`ACTIVE`].[Id,Name]' --output text
export AWS_MANAGEMENT_PROFILE=<your org management read-only profile>
run the account_discovery command to enumerate ACTIVE accounts
for each account, resolve its profile from ~/.aws/config and export AWS_OPERATIONS_PROFILE to it
repeat the single-account verify per account; a 0 result is a routing suspect, not a clean account -- re-check with sts get-caller-identity before concluding
Map each returned account id to its profile name from your own ~/.aws/config (sso_account_id -> profile). Never hardcode the mapping; it differs per operator and per tenant.
Confirm it works:
aws sts get-caller-identity --profile "$AWS_OPERATIONS_PROFILE" --output json | jq -r .Account   # must equal the account you resolved the profile for
How is this VPC wired, and is traffic actually reaching the resources it should?
awslabs-network
27 MCP toolswired · 2 products
Analyze VPC routing, transit gateway paths, and network flow logs.
Ask your agent
List the VPCs in this account, show the routing, subnets and security configuration of one of them, then pull its recent VPC Flow Logs so I can see any rejected traffic. Do not change anything.
Read-only: by_design
Set it up
One account
export AWS_OPERATIONS_PROFILE=<a read-only profile for the workload account that runs your VPCs>  # from ~/.aws/config; never committed
aws sso login --profile "$AWS_OPERATIONS_PROFILE"
aws sts get-caller-identity --profile "$AWS_OPERATIONS_PROFILE" --output json   # confirm the account is the one you intend
add the awslabs-network entry to your project's .mcp.json by running: python3 .claude/mcps/scripts/derive-mcp-profile.py --all-targets
Confirm it works:
aws ec2 describe-vpcs --profile "$AWS_OPERATIONS_PROFILE" --region "$AWS_REGION" --query 'length(Vpcs)' --output text
Landing zone (many accounts)
Find the accounts first:
aws organizations list-accounts --profile "$AWS_MANAGEMENT_PROFILE" --query 'Accounts[?Status==`ACTIVE`].[Id,Name]' --output text
export AWS_MANAGEMENT_PROFILE=<your org management read-only profile>
run the account_discovery command to enumerate ACTIVE accounts
for each account, resolve its profile from ~/.aws/config and export AWS_OPERATIONS_PROFILE to it
repeat the single-account verify per account; a 0 result is a routing suspect, not a clean account -- re-check with sts get-caller-identity before concluding
Map each returned account id to its profile name from your own ~/.aws/config (sso_account_id -> profile). Never hardcode the mapping; it differs per operator and per tenant.
Confirm it works:
aws sts get-caller-identity --profile "$AWS_OPERATIONS_PROFILE" --output json | jq -r .Account   # must equal the account you resolved the profile for
Which of our Lambda functions are erroring, what triggers them, and what would deploying a change involve?
awslabs-serverless
25 MCP toolsavailable · not wired
AWS SAM/Serverless deployment guidance, Lambda event-schema lookup, and (write-fenced) web-app deployment tooling.
Ask your agent
Show recent error metrics for our Lambda functions, pull the recent logs for the function with the most errors, list the event schemas that trigger it, then show the deployment guidance for changing it.
Read-only: enforced
Set it up
One account
export AWS_OPERATIONS_PROFILE=<your read-only profile>  # from ~/.aws/config; never committed
aws sso login --profile "$AWS_OPERATIONS_PROFILE"
aws sts get-caller-identity --profile "$AWS_OPERATIONS_PROFILE" --output json   # confirm the account is the one you intend
add the awslabs-serverless entry to your project's .mcp.json by running: python3 .claude/mcps/scripts/derive-mcp-profile.py --all-targets
Confirm it works:
aws lambda list-functions --profile "$AWS_OPERATIONS_PROFILE" --region "$AWS_REGION" --query 'length(Functions)' --output text
Landing zone (many accounts)
Find the accounts first:
aws organizations list-accounts --profile "$AWS_MANAGEMENT_PROFILE" --query 'Accounts[?Status==`ACTIVE`].[Id,Name]' --output text
export AWS_MANAGEMENT_PROFILE=<your org management read-only profile>
run the account_discovery command to enumerate ACTIVE accounts
for each account, resolve its profile from ~/.aws/config and export AWS_OPERATIONS_PROFILE to it
repeat the single-account verify per account; a 0 result is a routing suspect, not a clean account -- re-check with sts get-caller-identity before concluding
Map each returned account id to its profile name from your own ~/.aws/config (sso_account_id -> profile). Never hardcode the mapping; it differs per operator and per tenant.
Confirm it works:
aws sts get-caller-identity --profile "$AWS_OPERATIONS_PROFILE" --output json | jq -r .Account   # must equal the account you resolved the profile for

Data & Analytics

Before I provision a new DynamoDB table, what will it cost and will my access patterns actually work?
awslabs-dynamodb
8 MCP toolsavailable · not wired
Design DynamoDB data models, validate them against a local DynamoDB Local emulator, and estimate RCU/WCU cost -- not a live production-table browser.
Ask your agent
Take my described access patterns, design a DynamoDB schema for them, validate it against DynamoDB Local, and calculate the monthly RCU/WCU cost before I provision anything for real.
Read-only: by_design
Set it up
One account
export AWS_OPERATIONS_PROFILE=<your read-only profile>  # from ~/.aws/config; never committed
aws sso login --profile "$AWS_OPERATIONS_PROFILE"
aws sts get-caller-identity --profile "$AWS_OPERATIONS_PROFILE" --output json   # confirm the account is the one you intend
add the awslabs-dynamodb entry to your project's .mcp.json by running: python3 .claude/mcps/scripts/derive-mcp-profile.py --all-targets
Confirm it works:
aws sts get-caller-identity --profile "$AWS_OPERATIONS_PROFILE" --output json   # this server designs/validates schemas locally and does not query live tables, so identity resolution is the correct readiness check
Landing zone (many accounts)
Find the accounts first:
aws organizations list-accounts --profile "$AWS_MANAGEMENT_PROFILE" --query 'Accounts[?Status==`ACTIVE`].[Id,Name]' --output text
export AWS_MANAGEMENT_PROFILE=<your org management read-only profile>
run the account_discovery command to enumerate ACTIVE accounts
for each account, resolve its profile from ~/.aws/config and export AWS_OPERATIONS_PROFILE to it
repeat the single-account verify per account; a 0 result is a routing suspect, not a clean account -- re-check with sts get-caller-identity before concluding
Map each returned account id to its profile name from your own ~/.aws/config (sso_account_id -> profile). Never hardcode the mapping; it differs per operator and per tenant.
Confirm it works:
aws sts get-caller-identity --profile "$AWS_OPERATIONS_PROFILE" --output json | jq -r .Account   # must equal the account you resolved the profile for
awslabs-postgres
awslabs-postgres
6 MCP toolswired · 1 product
Answer questions from Aurora PostgreSQL data with a read-only SQL query path.
Read-only: enforced
What S3 table buckets and namespaces do we have, and can I query one with SQL?
awslabs-s3-tables
16 MCP toolsavailable · not wired
List S3 table buckets, namespaces and tables, and query them with SQL via PyIceberg/Daft.
Ask your agent
List our S3 table buckets and namespaces, then run a SQL query against one of the tables to show its row count.
Read-only: enforced
Set it up
One account
export AWS_OPERATIONS_PROFILE=<your read-only profile>  # from ~/.aws/config; never committed
aws sso login --profile "$AWS_OPERATIONS_PROFILE"
aws sts get-caller-identity --profile "$AWS_OPERATIONS_PROFILE" --output json   # confirm the account is the one you intend
add the awslabs-s3-tables entry to your project's .mcp.json by running: python3 .claude/mcps/scripts/derive-mcp-profile.py --all-targets
Confirm it works:
aws s3tables list-table-buckets --profile "$AWS_OPERATIONS_PROFILE" --region "$AWS_REGION" --query 'length(tableBuckets)' --output text
Landing zone (many accounts)
Find the accounts first:
aws organizations list-accounts --profile "$AWS_MANAGEMENT_PROFILE" --query 'Accounts[?Status==`ACTIVE`].[Id,Name]' --output text
export AWS_MANAGEMENT_PROFILE=<your org management read-only profile>
run the account_discovery command to enumerate ACTIVE accounts
for each account, resolve its profile from ~/.aws/config and export AWS_OPERATIONS_PROFILE to it
repeat the single-account verify per account; a 0 result is a routing suspect, not a clean account -- re-check with sts get-caller-identity before concluding
Map each returned account id to its profile name from your own ~/.aws/config (sso_account_id -> profile). Never hardcode the mapping; it differs per operator and per tenant.
Confirm it works:
aws sts get-caller-identity --profile "$AWS_OPERATIONS_PROFILE" --output json | jq -r .Account   # must equal the account you resolved the profile for

Integration & Messaging

Can Claude answer questions from one of our own REST APIs without us writing integration code?
awslabs-openapi
available · not wired
Expose an operator-supplied OpenAPI specification's operations as MCP tools (REST/HTTP proxy).
Ask your agent
Using the API described by our OpenAPI specification, list the read-only operations it exposes and call one of them to answer my question. Do not call any operation that creates, updates or deletes data.
Read-only: by_design
Set it up
One account
choose one API and note its OpenAPI specification URL (or a local specification file)
confirm the specification lists only the operations you are willing to let Claude call; every operation in it becomes a tool
add --api-name <short name> and --spec-url <specification URL> (or --spec-path <file>) to the awslabs-openapi args, plus the API's own authentication options
add the awslabs-openapi entry to your project's .mcp.json by running: python3 .claude/mcps/scripts/derive-mcp-profile.py --all-targets
Confirm it works:
curl -fsSL "<specification URL>" | jq '.paths | keys | length'   # the number of API paths that will become tools
Landing zone (many accounts)
list the APIs you want Claude to reach and their OpenAPI specification URLs
for each API, add a separately named server entry with its own --api-name, --spec-url and authentication options
run the single-account verify for each specification before wiring it
Confirm it works:
curl -fsSL "<specification URL>" | jq -r '.info.title'   # must name the API you intended for this entry
awslabs-sns-sqs
awslabs-sns-sqs
20 MCP toolswired · 1 product
Inspect and work with SNS topics and SQS queues.
Read-only: enforced
Is our AWS environment meeting Well-Architected security best practices right now?
awslabs-well-architected-security
6 MCP toolsavailable · not wired
Assess AWS environments against the Well-Architected Framework Security Pillar: network encryption-in-transit, enabled security services, storage encryption-at-rest, and aggregated security findings.
Ask your agent
Check whether our network resources enforce encryption in transit, confirm which AWS security services are enabled in this account and region, check whether our storage resources have encryption at rest enabled, and summarise any security findings.
Read-only: by_design
Set it up
One account
export AWS_OPERATIONS_PROFILE=<your read-only profile>  # from ~/.aws/config; never committed
aws sso login --profile "$AWS_OPERATIONS_PROFILE"
aws sts get-caller-identity --profile "$AWS_OPERATIONS_PROFILE" --output json   # confirm the account is the one you intend
add the awslabs-well-architected-security entry to your project's .mcp.json by running: python3 .claude/mcps/scripts/derive-mcp-profile.py --all-targets
Confirm it works:
aws securityhub describe-hub --profile "$AWS_OPERATIONS_PROFILE" --region "$AWS_REGION" --output json   # confirm Security Hub is reachable in this account/region
Landing zone (many accounts)
Find the accounts first:
aws organizations list-accounts --profile "$AWS_MANAGEMENT_PROFILE" --query 'Accounts[?Status==`ACTIVE`].[Id,Name]' --output text
export AWS_MANAGEMENT_PROFILE=<your org management read-only profile>
run the account_discovery command to enumerate ACTIVE accounts
for each account, resolve its profile from ~/.aws/config and export AWS_OPERATIONS_PROFILE to it
repeat the single-account verify per account; a 0 result is a routing suspect, not a clean account -- re-check with sts get-caller-identity before concluding
Map each returned account id to its profile name from your own ~/.aws/config (sso_account_id -> profile). Never hardcode the mapping; it differs per operator and per tenant.
Confirm it works:
aws sts get-caller-identity --profile "$AWS_OPERATIONS_PROFILE" --output json | jq -r .Account   # must equal the account you resolved the profile for
The AWS API MCP server is being retired upstream. How do we move to its successor without losing read-only access?
awslabs-api
2 MCP toolswired · 6 productsdeprecated
Call AWS APIs and discover relevant AWS commands.
Ask your agent
I use the AWS API MCP server, which AWS is retiring. Using the AWS MCP Server instead, confirm it is available in our AWS region and search the AWS documentation for how to run it read-only, then list the steps to switch over. Cite the pages you read.
Read-only: enforced

Across all services

Is the AWS service we want to adopt available in our region, and what does the current AWS documentation say about setting it up?
aws-mcp
6 MCP toolsavailable · not wired
Query AWS resources and services across your accounts.
Ask your agent
Check whether the AWS service I name is available in our AWS region, then search the current AWS documentation and summarise the setup steps. Cite the pages you read.
Read-only: enforced
Set it up
One account
export AWS_PROFILE=<your read-only profile>  # from ~/.aws/config; never committed
aws sso login --profile "$AWS_PROFILE"
aws sts get-caller-identity --profile "$AWS_PROFILE" --output json   # confirm the account is the one you intend
add the aws-mcp entry to your project's .mcp.json by running: python3 .claude/mcps/scripts/derive-mcp-profile.py --all-targets
Confirm it works:
aws sts get-caller-identity --profile "$AWS_PROFILE" --output json   # this server reads documentation and region data, not account resources, so identity resolution is the correct readiness check
Landing zone (many accounts)
Find the accounts first:
aws organizations list-accounts --profile "$AWS_MANAGEMENT_PROFILE" --query 'Accounts[?Status==`ACTIVE`].[Id,Name]' --output text
export AWS_MANAGEMENT_PROFILE=<your org management read-only profile>
run the account_discovery command only if a question depends on a specific account
for that account, resolve its profile from ~/.aws/config and export AWS_PROFILE to it
Usually not needed: documentation and region-availability answers are the same for every account. Only resolve a per-account profile from your own ~/.aws/config when a question depends on one account's enabled regions.
Confirm it works:
aws sts get-caller-identity --profile "$AWS_PROFILE" --output json | jq -r .Account   # must equal the account you resolved the profile for
The AWS API MCP server is being retired upstream. How do we move to its successor without losing read-only access?
awslabs-api
2 MCP toolswired · 6 productsdeprecated
Call AWS APIs and discover relevant AWS commands.
Ask your agent
I use the AWS API MCP server, which AWS is retiring. Using the AWS MCP Server instead, confirm it is available in our AWS region and search the AWS documentation for how to run it read-only, then list the steps to switch over. Cite the pages you read.
Read-only: enforced

Not connected, and why

These servers exist upstream and were tested, but are not wired in. Each line records what was measured and what would have to change.

awslabs-lambda-toolblocked
A CloudOps engineer needs to expose specific, pre-approved Lambda functions as agent-invokable tools.
Not connected: it can invoke any configured function and has no read-only mode to disable that.
awslabs-stepfunctionsblocked
A CloudOps engineer needs to trace failed Step Functions executions to the failing step and error.
Not connected: it can execute any state machine and has no read-only mode to disable that capability.
awslabs-security-agentblocked
A security engineer needs automated code security scans and threat-model reviews run from inside an agent session.
Not connected: it auto-provisions AWS resources on first use and has no read-only mode to prevent that.
aws-mcpready
A developer needs live AWS documentation, region availability, and long-task polling from inside an agent session, without the deprecated AWS API MCP Server's per-call round-trip model.
Available now: measured and read-only. Not yet added to products; this change is planned separately.