AWS

Generated from .claude/mcps/.mcp-enterprise.json on 2026-09-15 — do not edit this page by hand; run task mcp:docs instead. 15 server(s) from AWS, used across 6 product(s).

aws-mcp

Call AWS APIs across your accounts and search AWS documentation.

Tools: 8 — aws___get_presigned_url, aws___get_tasks, aws___run_script, aws___get_regional_availability, aws___list_regions, aws___read_documentation, aws___retrieve_skill, aws___search_documentation
Runs in: cloudops-runbooks, command-center, commerce, devops-terraform, finops-focus, platform-idp
Enable: Written into each target's .mcp.json by task mcp:profile:regenerate (or, for a tenant-scoped product, task tenant:launch TENANT=<id>).
Env vars: none
Auth: none
Verify: claude mcp list
Runbook: —

Ask it

Is the AWS service we want to adopt available in our region, and what does the current AWS documentation say about setting it up?

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.

Tools this prompt calls: aws___get_regional_availability, aws___search_documentation, aws___read_documentation.

Set up: one account

Environment: $AWS_PROFILE, $AWS_REGION.

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

Verify:

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

Set up: every account in a landing zone

Environment: $AWS_PROFILE, $AWS_REGION.

List the accounts (organizations:ListAccounts with $AWS_MANAGEMENT_PROFILE):

aws organizations list-accounts --profile "$AWS_MANAGEMENT_PROFILE" --query 'Accounts[?Status==`ACTIVE`].[Id,Name]' --output text

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.

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

Verify:

aws sts get-caller-identity --profile "$AWS_PROFILE" --output json | jq -r .Account   # must equal the account you resolved the profile for

awslabs-billing-cost-management

Analyze AWS costs, budgets, savings plans, and optimization opportunities.

Tools: 0
Runs in: cloudops-runbooks, command-center, finops-focus
Enable: Written into each target's .mcp.json by task mcp:profile:regenerate (or, for a tenant-scoped product, task tenant:launch TENANT=<id>).
Env vars: AWS_PROFILE, AWS_REGION, FASTMCP_LOG_LEVEL
Auth: env credential
Verify: claude mcp list
Runbook: —

Ask it

Where did our AWS spend go last month, what changed compared with the month before, and was any of it unexpected?

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.

Tools this prompt calls: cost-explorer, cost-comparison, cost-anomaly.

Set up: one account

Environment: $AWS_BILLING_PROFILE.

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

Verify:

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

Set up: every account in a landing zone

Environment: $AWS_BILLING_PROFILE.

List the accounts (organizations:ListAccounts with $AWS_MANAGEMENT_PROFILE):

aws organizations list-accounts --profile "$AWS_MANAGEMENT_PROFILE" --query 'Accounts[?Status==`ACTIVE`].[Id,Name]' --output text

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.

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

Verify:

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

awslabs-cloudtrail

Look up CloudTrail events and query CloudTrail Lake for privileged-API audit trail and compliance review.

Tools: 0
Runs in: cloudops-runbooks, command-center
Enable: Written into each target's .mcp.json by task mcp:profile:regenerate (or, for a tenant-scoped product, task tenant:launch TENANT=<id>).
Env vars: AWS_PROFILE, AWS_REGION, FASTMCP_LOG_LEVEL
Auth: env credential
Verify: claude mcp list
Runbook: —

Ask it

Who made privileged API calls recently, and what exactly did they do?

Look up the most recent CloudTrail events for privileged actions (create, delete, put, policy changes) and summarise who performed each one and when.

Tools this prompt calls: lookup_events.

Set up: one account

Environment: $AWS_OPERATIONS_PROFILE, $AWS_REGION.

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

Verify:

aws cloudtrail describe-trails --profile "$AWS_OPERATIONS_PROFILE" --region "$AWS_REGION" --query 'length(trailList)' --output text

Set up: every account in a landing zone

Environment: $AWS_OPERATIONS_PROFILE, $AWS_REGION.

List the accounts (organizations:ListAccounts with $AWS_MANAGEMENT_PROFILE):

aws organizations list-accounts --profile "$AWS_MANAGEMENT_PROFILE" --query 'Accounts[?Status==`ACTIVE`].[Id,Name]' --output text

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.

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

Verify:

aws sts get-caller-identity --profile "$AWS_OPERATIONS_PROFILE" --output json | jq -r .Account   # must equal the account you resolved the profile for

awslabs-cloudwatch

Query CloudWatch Logs Insights, metrics, and alarms for live observability and incident triage.

Tools: 0
Runs in: cloudops-runbooks, command-center
Enable: Written into each target's .mcp.json by task mcp:profile:regenerate (or, for a tenant-scoped product, task tenant:launch TENANT=<id>).
Env vars: AWS_PROFILE, AWS_REGION, FASTMCP_LOG_LEVEL
Auth: env credential
Verify: claude mcp list
Runbook: —

Ask it

Which CloudWatch alarms are in ALARM state right now, and what changed just before each one fired?

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.

Tools this prompt calls: get_active_alarms, get_alarm_history.

Set up: one account

Environment: $AWS_OPERATIONS_PROFILE, $AWS_REGION.

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

Verify:

aws cloudwatch describe-alarms --profile "$AWS_OPERATIONS_PROFILE" --region "$AWS_REGION" --query 'length(MetricAlarms)' --output text

Set up: every account in a landing zone

Environment: $AWS_OPERATIONS_PROFILE, $AWS_REGION.

List the accounts (organizations:ListAccounts with $AWS_MANAGEMENT_PROFILE):

aws organizations list-accounts --profile "$AWS_MANAGEMENT_PROFILE" --query 'Accounts[?Status==`ACTIVE`].[Id,Name]' --output text

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.

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

Verify:

aws sts get-caller-identity --profile "$AWS_OPERATIONS_PROFILE" --output json | jq -r .Account   # must equal the account you resolved the profile for

awslabs-dynamodb

Design DynamoDB data models, validate them against a local DynamoDB Local emulator, and estimate RCU/WCU cost -- not a live production-table browser.

Tools: 0
Runs in: no product target (slice-only)
Enable: Written into each target's .mcp.json by task mcp:profile:regenerate (or, for a tenant-scoped product, task tenant:launch TENANT=<id>).
Env vars: AWS_PROFILE, AWS_REGION, FASTMCP_LOG_LEVEL
Auth: env credential
Verify: claude mcp list
Runbook: —

Ask it

Before I provision a new DynamoDB table, what will it cost and will my access patterns actually work?

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.

Tools this prompt calls: dynamodb_data_modeling, dynamodb_data_model_validation, compute_performances_and_costs.

Set up: one account

Environment: $AWS_OPERATIONS_PROFILE, $AWS_REGION.

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

Verify:

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

Set up: every account in a landing zone

Environment: $AWS_OPERATIONS_PROFILE, $AWS_REGION.

List the accounts (organizations:ListAccounts with $AWS_MANAGEMENT_PROFILE):

aws organizations list-accounts --profile "$AWS_MANAGEMENT_PROFILE" --query 'Accounts[?Status==`ACTIVE`].[Id,Name]' --output text

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.

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

Verify:

aws sts get-caller-identity --profile "$AWS_OPERATIONS_PROFILE" --output json | jq -r .Account   # must equal the account you resolved the profile for

awslabs-ecs

Containerize applications and manage Amazon ECS services and tasks.

Tools: 0
Runs in: cloudops-runbooks, command-center, platform-idp
Enable: Written into each target's .mcp.json by task mcp:profile:regenerate (or, for a tenant-scoped product, task tenant:launch TENANT=<id>).
Env vars: ALLOW_SENSITIVE_DATA, ALLOW_WRITE, AWS_PROFILE, AWS_REGION, FASTMCP_LOG_LEVEL
Auth: env credential
Verify: claude mcp list
Runbook: —

Ask it

Which of our container services are not running as many tasks as they should, and why?

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.

Tools this prompt calls: ecs_resource_management, ecs_troubleshooting_tool.

Set up: one account

Environment: $AWS_OPERATIONS_PROFILE, $AWS_REGION.

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

Verify:

aws ecs list-clusters --profile "$AWS_OPERATIONS_PROFILE" --region "$AWS_REGION" --query 'length(clusterArns)' --output text

Set up: every account in a landing zone

Environment: $AWS_OPERATIONS_PROFILE, $AWS_REGION.

List the accounts (organizations:ListAccounts with $AWS_MANAGEMENT_PROFILE):

aws organizations list-accounts --profile "$AWS_MANAGEMENT_PROFILE" --query 'Accounts[?Status==`ACTIVE`].[Id,Name]' --output text

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.

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

Verify:

aws sts get-caller-identity --profile "$AWS_OPERATIONS_PROFILE" --output json | jq -r .Account   # must equal the account you resolved the profile for

awslabs-iac

Validate, troubleshoot and research CloudFormation and CDK infrastructure as code (no create/update/delete tools).

Tools: 0
Runs in: cloudops-runbooks, commerce, devops-terraform, platform-idp
Enable: Written into each target's .mcp.json by task mcp:profile:regenerate (or, for a tenant-scoped product, task tenant:launch TENANT=<id>).
Env vars: AWS_PROFILE, AWS_REGION, FASTMCP_LOG_LEVEL
Auth: env credential
Verify: claude mcp list
Runbook: —

Ask it

Why did this CloudFormation deployment fail, and will the corrected template pass our security rules before we try again?

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.

Tools this prompt calls: troubleshoot_cloudformation_deployment, validate_cloudformation_template, check_cloudformation_template_compliance.

Set up: one account

Environment: $AWS_OPERATIONS_PROFILE, $AWS_REGION.

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

Verify:

aws cloudformation describe-stacks --profile "$AWS_OPERATIONS_PROFILE" --region "$AWS_REGION" --query 'length(Stacks)' --output text

Set up: every account in a landing zone

Environment: $AWS_OPERATIONS_PROFILE, $AWS_REGION.

List the accounts (organizations:ListAccounts with $AWS_MANAGEMENT_PROFILE):

aws organizations list-accounts --profile "$AWS_MANAGEMENT_PROFILE" --query 'Accounts[?Status==`ACTIVE`].[Id,Name]' --output text

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.

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

Verify:

aws sts get-caller-identity --profile "$AWS_OPERATIONS_PROFILE" --output json | jq -r .Account   # must equal the account you resolved the profile for

awslabs-iam

Review IAM users, roles, groups and policies, and simulate policy evaluation for access review.

Tools: 0
Runs in: command-center
Enable: Written into each target's .mcp.json by task mcp:profile:regenerate (or, for a tenant-scoped product, task tenant:launch TENANT=<id>).
Env vars: AWS_PROFILE, AWS_REGION, FASTMCP_LOG_LEVEL
Auth: env credential
Verify: claude mcp list
Runbook: —

Ask it

Which roles and users can reach administrative access, and where is that permission actually attached?

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.

Tools this prompt calls: list_roles, list_users, list_policies, simulate_principal_policy.

Set up: one account

Environment: $AWS_OPERATIONS_PROFILE, $AWS_REGION.

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

Verify:

aws iam list-roles --profile "$AWS_OPERATIONS_PROFILE" --query 'length(Roles)' --output text

Set up: every account in a landing zone

Environment: $AWS_OPERATIONS_PROFILE, $AWS_REGION.

List the accounts (organizations:ListAccounts with $AWS_MANAGEMENT_PROFILE):

aws organizations list-accounts --profile "$AWS_MANAGEMENT_PROFILE" --query 'Accounts[?Status==`ACTIVE`].[Id,Name]' --output text

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.

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

Verify:

aws sts get-caller-identity --profile "$AWS_OPERATIONS_PROFILE" --output json | jq -r .Account   # must equal the account you resolved the profile for

awslabs-network

Analyze VPC routing, transit gateway paths, and network flow logs.

Tools: 0
Runs in: cloudops-runbooks, command-center
Enable: Written into each target's .mcp.json by task mcp:profile:regenerate (or, for a tenant-scoped product, task tenant:launch TENANT=<id>).
Env vars: AWS_PROFILE, AWS_REGION, FASTMCP_LOG_LEVEL
Auth: env credential
Verify: claude mcp list
Runbook: —

Ask it

How is this VPC wired, and is traffic actually reaching the resources it should?

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.

Tools this prompt calls: list_vpcs, get_vpc_network, get_vpc_flow_logs.

Set up: one account

Environment: $AWS_OPERATIONS_PROFILE, $AWS_REGION.

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

Verify:

aws ec2 describe-vpcs --profile "$AWS_OPERATIONS_PROFILE" --region "$AWS_REGION" --query 'length(Vpcs)' --output text

Set up: every account in a landing zone

Environment: $AWS_OPERATIONS_PROFILE, $AWS_REGION.

List the accounts (organizations:ListAccounts with $AWS_MANAGEMENT_PROFILE):

aws organizations list-accounts --profile "$AWS_MANAGEMENT_PROFILE" --query 'Accounts[?Status==`ACTIVE`].[Id,Name]' --output text

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.

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

Verify:

aws sts get-caller-identity --profile "$AWS_OPERATIONS_PROFILE" --output json | jq -r .Account   # must equal the account you resolved the profile for

awslabs-openapi

Expose an operator-supplied OpenAPI specification's operations as MCP tools (REST/HTTP proxy).

Tools: not measured (failed: server exited: Downloading chardet (1.4MiB) Downloaded chardet Installed 88 packages in 119ms realpath: --: No such file or directory 2026-09-12 23:21:16.067 | INFO | awslabs.openapi_mcp_server.utils.http_client:<module>:40 - tenacity retry logic enabled 2026-09-12 23:21:16.071 | INFO | awslabs.ope)
Runs in: no product target (slice-only)
Enable: Written into each target's .mcp.json by task mcp:profile:regenerate (or, for a tenant-scoped product, task tenant:launch TENANT=<id>).
Env vars: none
Auth: none
Verify: claude mcp list
Runbook: —

Ask it

Can Claude answer questions from one of our own REST APIs without us writing integration code?

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.

Set 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

Verify:

curl -fsSL "<specification URL>" | jq '.paths | keys | length'   # the number of API paths that will become tools

Set up: every account in a landing zone

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

Verify:

curl -fsSL "<specification URL>" | jq -r '.info.title'   # must name the API you intended for this entry

awslabs-postgres

Answer questions from Aurora PostgreSQL data with a read-only SQL query path.

Tools: 7 — run_query, get_table_schema, connect_to_database, is_database_connected, get_database_connection_info, create_cluster, get_job_status
Runs in: cloudops-runbooks
Enable: Written into each target's .mcp.json by task mcp:profile:regenerate (or, for a tenant-scoped product, task tenant:launch TENANT=<id>).
Env vars: AWS_PROFILE, AWS_REGION, FASTMCP_LOG_LEVEL
Auth: env credential
Verify: claude mcp list
Runbook: —

run_query

Run a SQL query against PostgreSQL

Use the run_query tool from the awslabs-postgres MCP server for my current task: Run a SQL query against PostgreSQL.

get_table_schema

Fetch table columns and comments from Postgres

Use the get_table_schema tool from the awslabs-postgres MCP server for my current task: Fetch table columns and comments from Postgres.

connect_to_database

Connect to a specific database and save the connection internally

Use the connect_to_database tool from the awslabs-postgres MCP server for my current task: Connect to a specific database and save the connection internally.

is_database_connected

Check if a connection has been established

Use the is_database_connected tool from the awslabs-postgres MCP server for my current task: Check if a connection has been established.

get_database_connection_info

Get all cached database connection information

Use the get_database_connection_info tool from the awslabs-postgres MCP server for my current task: Get all cached database connection information.

create_cluster

Create an Aurora Postgres cluster

Use the create_cluster tool from the awslabs-postgres MCP server for my current task: Create an Aurora Postgres cluster.

get_job_status

get background job status

Use the get_job_status tool from the awslabs-postgres MCP server for my current task: get background job status.

awslabs-s3-tables

List S3 table buckets, namespaces and tables, and query them with SQL via PyIceberg/Daft.

Tools: 0
Runs in: no product target (slice-only)
Enable: Written into each target's .mcp.json by task mcp:profile:regenerate (or, for a tenant-scoped product, task tenant:launch TENANT=<id>).
Env vars: AWS_PROFILE, AWS_REGION, FASTMCP_LOG_LEVEL
Auth: env credential
Verify: claude mcp list
Runbook: —

Ask it

What S3 table buckets and namespaces do we have, and can I query one with SQL?

List our S3 table buckets and namespaces, then run a SQL query against one of the tables to show its row count.

Tools this prompt calls: list_table_buckets, list_namespaces, list_tables, query_database.

Set up: one account

Environment: $AWS_OPERATIONS_PROFILE, $AWS_REGION.

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

Verify:

aws s3tables list-table-buckets --profile "$AWS_OPERATIONS_PROFILE" --region "$AWS_REGION" --query 'length(tableBuckets)' --output text

Set up: every account in a landing zone

Environment: $AWS_OPERATIONS_PROFILE, $AWS_REGION.

List the accounts (organizations:ListAccounts with $AWS_MANAGEMENT_PROFILE):

aws organizations list-accounts --profile "$AWS_MANAGEMENT_PROFILE" --query 'Accounts[?Status==`ACTIVE`].[Id,Name]' --output text

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.

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

Verify:

aws sts get-caller-identity --profile "$AWS_OPERATIONS_PROFILE" --output json | jq -r .Account   # must equal the account you resolved the profile for

awslabs-serverless

AWS SAM/Serverless deployment guidance, Lambda event-schema lookup, and (write-fenced) web-app deployment tooling.

Tools: 0
Runs in: no product target (slice-only)
Enable: Written into each target's .mcp.json by task mcp:profile:regenerate (or, for a tenant-scoped product, task tenant:launch TENANT=<id>).
Env vars: AWS_PROFILE, AWS_REGION, FASTMCP_LOG_LEVEL
Auth: env credential
Verify: claude mcp list
Runbook: —

Ask it

Which of our Lambda functions are erroring, what triggers them, and what would deploying a change involve?

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.

Tools this prompt calls: get_metrics, sam_logs, get_lambda_event_schemas, get_lambda_guidance.

Set up: one account

Environment: $AWS_OPERATIONS_PROFILE, $AWS_REGION.

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

Verify:

aws lambda list-functions --profile "$AWS_OPERATIONS_PROFILE" --region "$AWS_REGION" --query 'length(Functions)' --output text

Set up: every account in a landing zone

Environment: $AWS_OPERATIONS_PROFILE, $AWS_REGION.

List the accounts (organizations:ListAccounts with $AWS_MANAGEMENT_PROFILE):

aws organizations list-accounts --profile "$AWS_MANAGEMENT_PROFILE" --query 'Accounts[?Status==`ACTIVE`].[Id,Name]' --output text

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.

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

Verify:

aws sts get-caller-identity --profile "$AWS_OPERATIONS_PROFILE" --output json | jq -r .Account   # must equal the account you resolved the profile for

Inspect and work with SNS topics and SQS queues.

Tools: 43 — add_sns_permission, check_if_phone_number_is_opted_out, confirm_subscription, get_data_protection_policy, get_endpoint_attributes, get_platform_application_attributes, get_subscription_attributes, get_topic_attributes, list_endpoints_by_platform_application, list_origination_numbers, list_phone_numbers_opted_out, list_platform_applications, list_subscriptions, list_subscriptions_by_topic, list_tags_for_resource, list_topics, opt_in_phone_number, publish, publish_batch, put_data_protection_policy, set_subscription_attributes, set_topic_attributes, subscribe, unsubscribe, add_sqs_permission, cancel_message_move_task, change_message_visibility, change_message_visibility_batch, delete_message, delete_message_batch, get_queue_attributes, get_queue_url, list_dead_letter_source_queues, list_message_move_tasks, list_queue_tags, list_queues, purge_queue, receive_message, remove_sqs_permission, send_message, send_message_batch, set_queue_attributes, start_message_move_task
Runs in: cloudops-runbooks
Enable: Written into each target's .mcp.json by task mcp:profile:regenerate (or, for a tenant-scoped product, task tenant:launch TENANT=<id>).
Env vars: AWS_PROFILE, AWS_REGION, FASTMCP_LOG_LEVEL
Auth: env credential
Verify: claude mcp list
Runbook: —

Execute the AWS Amazon SNS add_permission operation.

Use the add_sns_permission tool from the awslabs-sns-sqs MCP server for my current task: Execute the AWS Amazon SNS `add_permission` operation.

Execute the AWS Amazon SNS check_if_phone_number_is_opted_out operation.

Use the check_if_phone_number_is_opted_out tool from the awslabs-sns-sqs MCP server for my current task: Execute the AWS Amazon SNS `check_if_phone_number_is_opted_out` operation.

Execute the AWS Amazon SNS confirm_subscription operation.

Use the confirm_subscription tool from the awslabs-sns-sqs MCP server for my current task: Execute the AWS Amazon SNS `confirm_subscription` operation.

Execute the AWS Amazon SNS get_data_protection_policy operation.

Use the get_data_protection_policy tool from the awslabs-sns-sqs MCP server for my current task: Execute the AWS Amazon SNS `get_data_protection_policy` operation.

Execute the AWS Amazon SNS get_endpoint_attributes operation.

Use the get_endpoint_attributes tool from the awslabs-sns-sqs MCP server for my current task: Execute the AWS Amazon SNS `get_endpoint_attributes` operation.

Execute the AWS Amazon SNS get_platform_application_attributes operation.

Use the get_platform_application_attributes tool from the awslabs-sns-sqs MCP server for my current task: Execute the AWS Amazon SNS `get_platform_application_attributes` operation.

Execute the AWS Amazon SNS get_subscription_attributes operation.

Use the get_subscription_attributes tool from the awslabs-sns-sqs MCP server for my current task: Execute the AWS Amazon SNS `get_subscription_attributes` operation.

Execute the AWS Amazon SNS get_topic_attributes operation.

Use the get_topic_attributes tool from the awslabs-sns-sqs MCP server for my current task: Execute the AWS Amazon SNS `get_topic_attributes` operation.

Execute the AWS Amazon SNS list_endpoints_by_platform_application operation.

Use the list_endpoints_by_platform_application tool from the awslabs-sns-sqs MCP server for my current task: Execute the AWS Amazon SNS `list_endpoints_by_platform_application` operation.

Execute the AWS Amazon SNS list_origination_numbers operation.

Use the list_origination_numbers tool from the awslabs-sns-sqs MCP server for my current task: Execute the AWS Amazon SNS `list_origination_numbers` operation.

Execute the AWS Amazon SNS list_phone_numbers_opted_out operation.

Use the list_phone_numbers_opted_out tool from the awslabs-sns-sqs MCP server for my current task: Execute the AWS Amazon SNS `list_phone_numbers_opted_out` operation.

Execute the AWS Amazon SNS list_platform_applications operation.

Use the list_platform_applications tool from the awslabs-sns-sqs MCP server for my current task: Execute the AWS Amazon SNS `list_platform_applications` operation.

Execute the AWS Amazon SNS list_subscriptions operation.

Use the list_subscriptions tool from the awslabs-sns-sqs MCP server for my current task: Execute the AWS Amazon SNS `list_subscriptions` operation.

Execute the AWS Amazon SNS list_subscriptions_by_topic operation.

Use the list_subscriptions_by_topic tool from the awslabs-sns-sqs MCP server for my current task: Execute the AWS Amazon SNS `list_subscriptions_by_topic` operation.

Execute the AWS Amazon SNS list_tags_for_resource operation.

Use the list_tags_for_resource tool from the awslabs-sns-sqs MCP server for my current task: Execute the AWS Amazon SNS `list_tags_for_resource` operation.

Execute the AWS Amazon SNS list_topics operation.

Use the list_topics tool from the awslabs-sns-sqs MCP server for my current task: Execute the AWS Amazon SNS `list_topics` operation.

Execute the AWS Amazon SNS opt_in_phone_number operation.

Use the opt_in_phone_number tool from the awslabs-sns-sqs MCP server for my current task: Execute the AWS Amazon SNS `opt_in_phone_number` operation.

Execute the AWS Amazon SNS publish operation.

Use the publish tool from the awslabs-sns-sqs MCP server for my current task: Execute the AWS Amazon SNS `publish` operation.

Execute the AWS Amazon SNS publish_batch operation.

Use the publish_batch tool from the awslabs-sns-sqs MCP server for my current task: Execute the AWS Amazon SNS `publish_batch` operation.

Execute the AWS Amazon SNS put_data_protection_policy operation.

Use the put_data_protection_policy tool from the awslabs-sns-sqs MCP server for my current task: Execute the AWS Amazon SNS `put_data_protection_policy` operation.

Execute the AWS Amazon SNS set_subscription_attributes operation.

Use the set_subscription_attributes tool from the awslabs-sns-sqs MCP server for my current task: Execute the AWS Amazon SNS `set_subscription_attributes` operation.

Execute the AWS Amazon SNS set_topic_attributes operation.

Use the set_topic_attributes tool from the awslabs-sns-sqs MCP server for my current task: Execute the AWS Amazon SNS `set_topic_attributes` operation.

Execute AWS SNS Subscribe. Ensure that you set correct permission policies if required.

Use the subscribe tool from the awslabs-sns-sqs MCP server for my current task: Execute AWS SNS Subscribe. Ensure that you set correct permission policies if required.

Execute the AWS Amazon SNS unsubscribe operation.

Use the unsubscribe tool from the awslabs-sns-sqs MCP server for my current task: Execute the AWS Amazon SNS `unsubscribe` operation.

Execute the AWS Amazon SQS add_permission operation.

Use the add_sqs_permission tool from the awslabs-sns-sqs MCP server for my current task: Execute the AWS Amazon SQS `add_permission` operation.

Execute the AWS Amazon SQS cancel_message_move_task operation.

Use the cancel_message_move_task tool from the awslabs-sns-sqs MCP server for my current task: Execute the AWS Amazon SQS `cancel_message_move_task` operation.

Execute the AWS Amazon SQS change_message_visibility operation.

Use the change_message_visibility tool from the awslabs-sns-sqs MCP server for my current task: Execute the AWS Amazon SQS `change_message_visibility` operation.

Execute the AWS Amazon SQS change_message_visibility_batch operation.

Use the change_message_visibility_batch tool from the awslabs-sns-sqs MCP server for my current task: Execute the AWS Amazon SQS `change_message_visibility_batch` operation.

Execute the AWS Amazon SQS delete_message operation.

Use the delete_message tool from the awslabs-sns-sqs MCP server for my current task: Execute the AWS Amazon SQS `delete_message` operation.

Execute the AWS Amazon SQS delete_message_batch operation.

Use the delete_message_batch tool from the awslabs-sns-sqs MCP server for my current task: Execute the AWS Amazon SQS `delete_message_batch` operation.

Execute the AWS Amazon SQS get_queue_attributes operation.

Use the get_queue_attributes tool from the awslabs-sns-sqs MCP server for my current task: Execute the AWS Amazon SQS `get_queue_attributes` operation.

Execute the AWS Amazon SQS get_queue_url operation.

Use the get_queue_url tool from the awslabs-sns-sqs MCP server for my current task: Execute the AWS Amazon SQS `get_queue_url` operation.

Execute the AWS Amazon SQS list_dead_letter_source_queues operation.

Use the list_dead_letter_source_queues tool from the awslabs-sns-sqs MCP server for my current task: Execute the AWS Amazon SQS `list_dead_letter_source_queues` operation.

Execute the AWS Amazon SQS list_message_move_tasks operation.

Use the list_message_move_tasks tool from the awslabs-sns-sqs MCP server for my current task: Execute the AWS Amazon SQS `list_message_move_tasks` operation.

Execute the AWS Amazon SQS list_queue_tags operation.

Use the list_queue_tags tool from the awslabs-sns-sqs MCP server for my current task: Execute the AWS Amazon SQS `list_queue_tags` operation.

Execute the AWS Amazon SQS list_queues operation.

Use the list_queues tool from the awslabs-sns-sqs MCP server for my current task: Execute the AWS Amazon SQS `list_queues` operation.

Execute the AWS Amazon SQS purge_queue operation.

Use the purge_queue tool from the awslabs-sns-sqs MCP server for my current task: Execute the AWS Amazon SQS `purge_queue` operation.

Execute the AWS Amazon SQS receive_message operation.

Use the receive_message tool from the awslabs-sns-sqs MCP server for my current task: Execute the AWS Amazon SQS `receive_message` operation.

Execute the AWS Amazon SQS remove_permission operation.

Use the remove_sqs_permission tool from the awslabs-sns-sqs MCP server for my current task: Execute the AWS Amazon SQS `remove_permission` operation.

Execute the AWS Amazon SQS send_message operation.

Use the send_message tool from the awslabs-sns-sqs MCP server for my current task: Execute the AWS Amazon SQS `send_message` operation.

Execute the AWS Amazon SQS send_message_batch operation.

Use the send_message_batch tool from the awslabs-sns-sqs MCP server for my current task: Execute the AWS Amazon SQS `send_message_batch` operation.

Execute the AWS Amazon SQS set_queue_attributes operation.

Use the set_queue_attributes tool from the awslabs-sns-sqs MCP server for my current task: Execute the AWS Amazon SQS `set_queue_attributes` operation.

Execute the AWS Amazon SQS start_message_move_task operation.

Use the start_message_move_task tool from the awslabs-sns-sqs MCP server for my current task: Execute the AWS Amazon SQS `start_message_move_task` operation.

awslabs-well-architected-security

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.

Tools: 6 — CheckNetworkSecurity, CheckSecurityServices, CheckStorageEncryption, GetSecurityFindings, GetStoredSecurityContext, ListServicesInRegion
Runs in: no product target (slice-only)
Enable: Written into each target's .mcp.json by task mcp:profile:regenerate (or, for a tenant-scoped product, task tenant:launch TENANT=<id>).
Env vars: AWS_PROFILE, AWS_REGION, FASTMCP_LOG_LEVEL
Auth: env credential
Verify: claude mcp list
Runbook: —

Ask it

Is our AWS environment meeting Well-Architected security best practices right now?

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.

Tools this prompt calls: CheckNetworkSecurity, CheckSecurityServices, CheckStorageEncryption, GetSecurityFindings, GetStoredSecurityContext, ListServicesInRegion.

Set up: one account

Environment: $AWS_OPERATIONS_PROFILE, $AWS_REGION.

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

Verify:

aws securityhub describe-hub --profile "$AWS_OPERATIONS_PROFILE" --region "$AWS_REGION" --output json   # confirm Security Hub is reachable in this account/region

Set up: every account in a landing zone

Environment: $AWS_OPERATIONS_PROFILE, $AWS_REGION.

List the accounts (organizations:ListAccounts with $AWS_MANAGEMENT_PROFILE):

aws organizations list-accounts --profile "$AWS_MANAGEMENT_PROFILE" --query 'Accounts[?Status==`ACTIVE`].[Id,Name]' --output text

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.

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

Verify:

aws sts get-caller-identity --profile "$AWS_OPERATIONS_PROFILE" --output json | jq -r .Account   # must equal the account you resolved the profile for

aws-mcp​

Ask it​

Set up: one account​

Set up: every account in a landing zone​

awslabs-billing-cost-management​

Ask it​

Set up: one account​

Set up: every account in a landing zone​

awslabs-cloudtrail​

Ask it​

Set up: one account​

Set up: every account in a landing zone​

awslabs-cloudwatch​

Ask it​

Set up: one account​

Set up: every account in a landing zone​

awslabs-dynamodb​

Ask it​

Set up: one account​

Set up: every account in a landing zone​

awslabs-ecs​

Ask it​

Set up: one account​

Set up: every account in a landing zone​

awslabs-iac​

Ask it​

Set up: one account​

Set up: every account in a landing zone​

awslabs-iam​

Ask it​

Set up: one account​

Set up: every account in a landing zone​

awslabs-network​

Ask it​

Set up: one account​

Set up: every account in a landing zone​

awslabs-openapi​

Ask it​

Set up: one account​

Set up: every account in a landing zone​

awslabs-postgres​

run_query​

get_table_schema​

connect_to_database​

is_database_connected​

get_database_connection_info​

create_cluster​

get_job_status​

awslabs-s3-tables​

Ask it​

Set up: one account​

Set up: every account in a landing zone​

awslabs-serverless​

Ask it​

Set up: one account​

Set up: every account in a landing zone​

awslabs-sns-sqs​

add_sns_permission​

check_if_phone_number_is_opted_out​

confirm_subscription​

get_data_protection_policy​

get_endpoint_attributes​

get_platform_application_attributes​

get_subscription_attributes​

get_topic_attributes​

list_endpoints_by_platform_application​

list_origination_numbers​

list_phone_numbers_opted_out​

list_platform_applications​

list_subscriptions​

list_subscriptions_by_topic​

list_tags_for_resource​

list_topics​

opt_in_phone_number​

publish​

publish_batch​

put_data_protection_policy​

set_subscription_attributes​

set_topic_attributes​

subscribe​

aws-mcp

Ask it

Set up: one account

Set up: every account in a landing zone

awslabs-billing-cost-management

Ask it

Set up: one account

Set up: every account in a landing zone

awslabs-cloudtrail

Ask it

Set up: one account

Set up: every account in a landing zone

awslabs-cloudwatch

Ask it

Set up: one account

Set up: every account in a landing zone

awslabs-dynamodb

Ask it

Set up: one account

Set up: every account in a landing zone

awslabs-ecs

Ask it

Set up: one account

Set up: every account in a landing zone

awslabs-iac

Ask it

Set up: one account

Set up: every account in a landing zone

awslabs-iam

Ask it

Set up: one account

Set up: every account in a landing zone

awslabs-network

Ask it

Set up: one account

Set up: every account in a landing zone

awslabs-openapi

Ask it

Set up: one account

Set up: every account in a landing zone

awslabs-postgres

run_query

get_table_schema

connect_to_database

is_database_connected

get_database_connection_info

create_cluster

get_job_status

awslabs-s3-tables

Ask it

Set up: one account

Set up: every account in a landing zone

awslabs-serverless

Ask it

Set up: one account

Set up: every account in a landing zone

awslabs-sns-sqs

add_sns_permission

check_if_phone_number_is_opted_out

confirm_subscription

get_data_protection_policy

get_endpoint_attributes

get_platform_application_attributes

get_subscription_attributes

get_topic_attributes

list_endpoints_by_platform_application

list_origination_numbers

list_phone_numbers_opted_out

list_platform_applications

list_subscriptions

list_subscriptions_by_topic

list_tags_for_resource

list_topics

opt_in_phone_number

publish

publish_batch

put_data_protection_policy

set_subscription_attributes

set_topic_attributes

subscribe