Amazon AWS operations workspace with S3, RDS, DynamoDB, Lambda, CloudWatch, Cost Explorer, and CodeBuild

The problem

Cloud teams bounce between the S3 console, RDS and DynamoDB tables, Lambda functions, CloudWatch logs and alarms, Cost Explorer reports, and CodeBuild history. Context gets lost, spend spikes hide behind noisy metrics, and incident reviews take longer than the outage itself.

Example prompt

Using the private gateway, build today's AWS ops brief. List S3 buckets with recent object activity, summarize RDS instances and DynamoDB tables that look unhealthy or idle, check Lambda functions invoked in the last 24 hours with elevated errors in CloudWatch, pull Cost Explorer spend by service for the last 7 days with a short forecast, and list the latest CodeBuild runs that failed. Do not put objects, execute SQL, invoke functions, mutate DynamoDB items, or start builds until I approve.

Gateway tool bundle

Use namespaced tools on the private gateway (personal workspace) or business gateway (company workspace):

Amazon S3 (read-first)

• s3__list_buckets → s3__list_objects for bucket inventory
• s3__head_object → s3__get_object for object metadata and content
• s3__put_object, s3__delete_object, s3__copy_object — writes only after explicit approval

Amazon RDS (read-first)

• rds__list_db_instances → rds__get_db_instance for instance health
• rds__list_db_clusters → rds__get_db_cluster for Aurora-style clusters
• rds__list_db_snapshots, rds__describe_db_events for recovery and recent events
• rds__query_sql — read-only SQL; keep rds__execute_sql gated

Amazon DynamoDB (read-first)

• dynamodb__list_tables → dynamodb__describe_table for schema and capacity
• dynamodb__query_table, dynamodb__scan_table, dynamodb__get_item for data inspection
• dynamodb__put_item, dynamodb__update_item, dynamodb__delete_item, and table create/update/delete — mutate only after approval

AWS Lambda (read-first)

• lambda__list_functions → lambda__get_function / lambda__get_function_configuration
• lambda__list_versions_by_function, lambda__list_aliases, lambda__list_event_source_mappings
• lambda__invoke_function — invoke only after explicit approval

AWS CloudWatch (observability)

• cloudwatch__list_log_groups → cloudwatch__filter_log_events / cloudwatch__get_log_events
• cloudwatch__list_metrics → cloudwatch__get_metric_data for error and latency signals
• cloudwatch__describe_alarms for active alarm state
• cloudwatch__start_logs_insights_query → cloudwatch__get_logs_insights_results for deeper log analysis

AWS Cost Explorer (spend)

• cost-explorer__get_cost_and_usage — daily/weekly spend by service
• cost-explorer__get_cost_forecast, cost-explorer__get-usage-forecast-tool
• cost-explorer__get_dimension_values, cost-explorer__get_tags for filtering
• cost-explorer__get_savings_plans_utilization, cost-explorer__get_reservation_utilization for commitment coverage

AWS CodeBuild (CI)

• codebuild__list_projects → codebuild__list-builds-tool → codebuild__get_build
• codebuild__get_build_logs, codebuild__list_build_artifacts
• codebuild__start_build, codebuild__stop_build — mutate CI only after approval

Start with list-services-tool or describe-service-tool to confirm which Amazon/AWS integrations are connected.

Token scope recommendations

Private gateway (recommended for individual operators)

• Scope API tokens to mcp:private-gateway so agents discover your connected AWS integrations.
• Add per-integration scopes when you need tighter control, for example mcp:s3, mcp:rds, mcp:dynamodb, mcp:lambda, mcp:cloudwatch, mcp:cost-explorer, and mcp:codebuild without granting * full access.

Business gateway (recommended for shared cloud ops teams)

• Scope API tokens to mcp:business-gateway so agents discover only integrations your company allowlist permits.
• Bind tokens to a company environment (production vs staging) when AWS accounts or regions must not mix.

Least-privilege example

{
  "abilities": [
    "mcp:private-gateway"
  ]
}

For read-only ops reviews, instruct agents to call only list-*, get-*, describe-*, query-*, filter-*, and Cost Explorer get-* tools. Keep put-*, delete-*, execute_sql, invoke_function, DynamoDB mutate tools, and start_build out of automated playbooks until a human approves each action.

Company integrations checklist

1. Enable AWS types in company settings — add S3, RDS, DynamoDB, Lambda, CloudWatch, Cost Explorer, and CodeBuild to the company integration allowlist before members connect.
2. Connect IAM credentials per environment — use least-privilege IAM users or roles; prefer separate staging and production credentials.
3. Align regions — confirm each integration’s region matches the AWS resources your team operates.
4. Issue a gateway token — scope to mcp:private-gateway / mcp:business-gateway or explicit mcp:{type} abilities; avoid empty selection that defaults to full access.
5. Verify with a read-only prompt — run the example prompt above and confirm audit logs attribute calls to the correct workspace and environment.

Governance

• Read-first by default: treat every Amazon/AWS integration as a read source until a human approves a write, invoke, SQL execute, or build start.
• Write tools off by default: s3__put_object, s3__delete_object, rds__execute_sql, DynamoDB put-item / update-item / delete-item / table lifecycle tools, lambda__invoke_function, and codebuild__start_build should run only after explicit approval in the agent prompt.
• Cost and production data sensitivity: Cost Explorer and CloudWatch may expose account topology and spend; redact account IDs and resource ARNs before sharing externally, and review Audit logs.
• Blast radius: IAM keys unlock multiple services — rotate credentials after shared demos, and never paste secret keys into prompts.