Skip to main content
Glama
YawLabs

@yawlabs/aws-mcp

Official
by YawLabs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

aws_multi_region

Destructive

Execute an AWS API operation across multiple regions in parallel, returning per-region results and errors. Ideal for fleet-wide reads such as describe-instances or list-buckets across all regions.

Instructions

Run the same AWS API operation across multiple regions in parallel. Same shape as aws_call (service, operation, params?, query?, outputFormat?, timeoutMs?) but takes regions: string[] instead of region, up to 64 per call with at most 32 in flight. Returns an array of {region, ok, data?, command?, error?, errorKind?} -- partial failure is expected (services aren't everywhere, perms may be region-scoped). Duplicate regions in the input are collapsed (first occurrence wins), so results.length may be less than regions.length; use the returned regionCount for the actual count run. The whole batch is capped at 5 MB of results: if it would exceed that, later entries keep their status but lose data and are flagged truncated: true, with the affected regions listed in a top-level truncatedRegions -- re-run those regions individually or narrow with query/params. Use for fleet-wide reads: 'describe-instances across all our regions', 'list buckets in every region', 'check IAM password policy everywhere'.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryNoJMESPath expression for --query (server-side trimming per region).
paramsNoOperation parameters (PascalCase keys) -- same shape as aws_call.
profileNoOverride session profile for the batch.
regionsYesRegion IDs (e.g. ['us-east-1','us-west-2','eu-west-1']). 1-64. Validated for argv-safety; a bad region name yields a clear per-region error and skips its CLI spawn (per-region isolation comes from each region being a separate call, not from this pre-check).
serviceYesAWS service in kebab-case: 's3api', 'ec2', 'iam', etc.
operationYesOperation in kebab-case: 'describe-instances', 'list-buckets', etc.
timeoutMsNoTimeout in ms applied PER region. Default 60000.
concurrencyNoMax regions in flight at once (1-32). Default 8.
outputFormatNoOutput format. Default 'json'.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv2.5.0
    • changedInput schema / properties / regions / description
      Previous value: -"Region IDs (e.g. ['us-east-1','us-west-2','eu-west-1']). 1-32. Validated for argv-safety; a bad region name yields a clear per-region error and skips its CLI spawn (per-region isolation comes from each region being a separate call, not from this pre-check)."New value: +"Region IDs (e.g. ['us-east-1','us-west-2','eu-west-1']). 1-64. Validated for argv-safety; a bad region name yields a clear per-region error and skips its CLI spawn (per-region isolation comes from each region being a separate call, not from this pre-check)."
    • changedInput schema / properties / regions / maxItems
      Previous value: -32New value: +64
  2. Changed1 schema field changedv1.5.1
    • changedInput schema / properties / regions / description
      Previous value: -"Region IDs (e.g. ['us-east-1','us-west-2','eu-west-1']). 1-32. Validated for argv-safety; bad region names fail per-region rather than poisoning the batch."New value: +"Region IDs (e.g. ['us-east-1','us-west-2','eu-west-1']). 1-32. Validated for argv-safety; a bad region name yields a clear per-region error and skips its CLI spawn (per-region isolation comes from each region being a separate call, not from this pre-check)."
  3. First observedv1.3.2

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations carry only broad hints, while the description discloses important behaviors: partial failure is expected, duplicate regions are collapsed, results are capped at 5 MB with truncated data flagged, and truncation recovery is described. It also explains per-region error isolation and the result/error shape. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but every sentence earns its place. It front-loads the core behavior, then covers result shape, failure modes, truncation, duplicate handling, and usage examples in a logical flow. The length is justified by the tool's complex behavior and remains well-organized.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, yet the description fully specifies the return shape: array of {region, ok, data?, command?, error?, errorKind?}, plus regionCount, truncated, and truncatedRegions. It also covers concurrency limits, per-region timeouts, partial failure, and re-running strategies. An agent has everything needed to invoke and interpret the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents every parameter. The description adds semantics that the schema cannot: regions max 64, at most 32 in flight, duplicate collapse with first-wins, and how query/params can narrow truncated results. This is meaningful added value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence states a specific verb and resource: run an AWS API operation across multiple regions in parallel. It immediately contrasts with aws_call by noting the regions parameter difference, and the examples (describe-instances, list buckets) clarify the intended use. This is fully distinguishable from siblings like aws_multi_account.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says 'Use for fleet-wide reads' and gives concrete examples, which makes the primary when-to-use case clear. It also references aws_call as the single-region counterpart, though it stops short of explicitly stating 'do not use this for single-region calls.'

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools