Related Servers

Most tools map to a single distinct resource (queues, topics, secrets, S3, CloudFront, Cognito, API routes) with explicit 'use X instead of Y' guidance, and the four index-suggestion tools are cleanly separated by engine. A few boundaries need reading the description to resolve: get_infra_overview vs get_graph_summary vs get_table_schema, get_lambda_overview vs analyze_function, and get_topic_details which also claims Kafka topic mappings that overlap with get_stream_details. get_log_errors is a genuinely confusing name given it explicitly does not return errors.

The bulk of tools follow a clean get_<resource>_overview/details pattern, but the index-suggestion family breaks it three ways: postgres_index_suggestions and mysql_index_suggestions put the verb last while suggest_mongo_index and suggest_gsi put it first. analyze_function and get_log_errors (a legacy name that contradicts its behavior) are further deviations. Still readable, but not a predictable pattern an agent can pattern-match on.

22 tools is on the heavy side, but the server covers an entire AWS account surface and each tool maps to a distinct service or engine, so nearly all earn their place. The dashboard-style overview tools (infra_overview, graph_summary, lambda_overview) plus 12 per-service overviews is a defensible decomposition rather than sprawl.

Coverage across compute, messaging, storage, caching, edge, auth, config, and data layers is strong, and index/GSI advice plus schema lookups close the loop from finding to fix. Gaps exist for common adjacent services (IAM roles/permissions, VPC/networking, Step Functions, ECS) and the index tools deliberately do not check for existing indexes, forcing a get_table_schema detour. The surface is read/advise-only by design, so the lack of mutation tools is not a completeness fault.