Skip to main content
Glama
YawLabs

@yawlabs/aws-mcp

Official
by YawLabs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

aws_multi_account

Destructive

Run the same AWS API operation across multiple accounts in parallel by assuming a specified role in each. Returns per-account results with partial failures reported.

Instructions

Run the same AWS API operation across multiple ACCOUNTS in parallel by assuming the same role name in each. Same shape as aws_call (service, operation, params?, query?, outputFormat?, region?, timeoutMs?) plus accounts: string[] of 12-digit account IDs and roleName. This is fan-out in one call, not new access: it is exactly what aws_assume_role in a loop would reach, minus the credentials-file churn -- each account's session is held in memory for the one subprocess that uses it and is NEVER written to ~/.aws/credentials, so a sweep that dies halfway leaves nothing on disk. If your org already runs a Config aggregator or Resource Explorer, those answer indexed inventory questions with less work; reach for this when you want an arbitrary API operation across accounts with no setup. Returns an array of {accountId, ok, data?, command?, error?, errorKind?} -- partial failure is expected and normal (the role may not exist in every account, trust policies differ, services vary). Duplicate account IDs collapse (first occurrence wins), so use the returned accountCount. The batch is capped at 5 MB of results: past that, entries keep their status but lose data and are flagged truncated: true, with the affected accounts listed in a top-level truncatedAccounts.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryNoJMESPath expression for --query (server-side trimming per account).
paramsNoOperation parameters (PascalCase keys) -- same shape as aws_call.
regionNoRegion for BOTH the sts:AssumeRole call and the operation. Defaults to the session region.
profileNoProfile to assume FROM -- your own identity, used for every sts:AssumeRole in the batch. Defaults to the session profile / $AWS_PROFILE. The target accounts never use a profile at all.
serviceYesAWS service in kebab-case: 's3api', 'ec2', 'iam', etc.
accountsYesTarget AWS account IDs, 12 digits each (e.g. ['111111111111','222222222222']). 1-32. A malformed ID fails only its own entry and does not spawn a CLI call.
roleNameYesName of the role to assume in EVERY target account (e.g. 'OrganizationAccountAccessRole', 'ReadOnlyAuditor'). Combined with each account ID into arn:aws:iam::<account>:role/<roleName>. Include the IAM path if the role has one ('engineering/Auditor').
operationYesOperation in kebab-case: 'describe-instances', 'get-caller-identity', 'list-buckets', etc.
timeoutMsNoTimeout in ms applied PER aws CLI spawn. Each account makes two: the sts:AssumeRole and the operation. Unset, the assume gets 120000 ms (headroom for cold-start SAML / credential_process) and the operation gets the standard 60000 ms; setting this applies one value to both.
concurrencyNoMax accounts in flight at once (1-32). Default 8.
sessionNameNoRole session name recorded in each target account's CloudTrail. Default 'aws-mcp-multi-account'. Alphanumeric + +=,.@- only, 2-64 chars.
outputFormatNoOutput format. Default 'json'.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.2.2

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only cover the read/write safety profile; the description adds substantial behavior beyond that: sessions held in memory and NEVER written to ~/.aws/credentials, partial failure is expected and normal, duplicate IDs collapse on first occurrence, and a 5 MB result cap that drops `data` and sets `truncated: true`. None of this contradicts the annotations (destructive/openWorld is consistent with running arbitrary operations).

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

Conciseness4/5

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

Dense but front-loaded: purpose first, then fan-out semantics, alternatives, return shape, then edge cases. It is a long single paragraph and every sentence carries information, though the return-shape and truncation detail could be trimmed if an output schema existed.

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?

For a 12-parameter, nested, no-output-schema tool, the description supplies the missing output contract in prose ({accountId, ok, data?, command?, error?, errorKind?}), plus partial-failure and truncation semantics. An agent has everything needed to call and interpret results.

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 baseline is 3, but the description adds real meaning: it frames the parameter set as 'same shape as aws_call', explains that duplicate account IDs collapse, points to the returned accountCount, and describes where roleName lands (per-account ARN, session name in CloudTrail). Slightly above baseline.

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?

Opens with a specific verb+resource+scope: 'Run the same AWS API operation across multiple ACCOUNTS in parallel by assuming the same role name in each.' It explicitly positions itself against siblings (aws_call shape, aws_assume_role in a loop, aws_multi_region is implied by naming accounts vs regions), so an agent can distinguish it without opening schemas.

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

Usage Guidelines5/5

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

Gives explicit when-to-use and when-not: it names two alternatives (Config aggregator, Resource Explorer) as lower-effort for indexed inventory questions, and states the condition that selects this tool ('arbitrary API operation across accounts with no setup'). This is about as clear as routing guidance gets.

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