Loading ToolBench
Exposes AWS fleet execution tools over the Model Context Protocol (stdio transport). Provides structured tools for discovering AWS targets, planning operations, executing plans with approval boundaries, and managing executions across multiple AWS accounts and regions.
awsmux demonstrates strong tool design with clear naming (verb_noun pattern), comprehensive parameter schemas, and detailed descriptions. All 5 tools follow consistent patterns with well-structured JSON schemas. Descriptions are detailed (150-400 chars) and explain WHEN to use each tool. However, output schemas are not documented, LLMs cannot predict response structure. Error handling guidance is minimal. Tool composition is excellent: list_aws_targets → plan_aws_operation → execute_aws_plan forms a clear chain with proper ID threading. Security considerations (approval tokens, risk classification) are well-integrated into the design.
Cancel a running background execution started via execute_aws_plan with wait false. In-flight targets are interrupted, unstarted targets are marked skipped, and the partial execution is persisted to history. Errors if the execution id is unknown or the run already finished.
Execute a plan created by plan_aws_operation across all its targets with a concurrent worker pool. Each plan executes at most once. If the plan has requires_approval true you MUST supply approval_token, obtained by a human running "awsmux approve <plan-id>"; there is no bypass, so if you have no token, ask the human to approve first. read_only plans need no token. With wait true (the default) this blocks and returns the finished execution: a summary plus results grouped by identical outcome, so a fleet-wide check where most targets agree comes back tiny. Oversized results are truncated with a next_offset for paging via get_aws_execution. With wait false it returns an execution_id immediately; poll get_aws_execution and use cancel_aws_execution to stop it.
Fetch one execution by id. A still-running background execution (started via execute_aws_plan with wait false) reports status "running" with a count of targets completed so far; a finished execution returns grouped results and a summary, like execute_aws_plan. Pass offset (and optionally limit) to page through per-target rows of a large result instead. Also works for any past execution in history.
Discover AWS execution targets (profile plus region pairs) from the local AWS shared config and credentials files. Use this first, before planning, to see exactly which accounts and principals an operation would touch. By default every target is preflighted with sts get-caller-identity, filling account_id and principal and surfacing credential problems; set preflight to false to skip that. Set dedupe to drop targets that resolve to the same account, principal, and region as an earlier one. Set ou or account_tags to select by AWS Organizations structure instead of profile name; the response then also reports matched org accounts that have no local profile.
Output schemas not documented. LLMs cannot predict response structure for list_aws_targets, plan_aws_operation, execute_aws_plan, get_aws_execution, or cancel_aws_execution. This forces agents to reason about unknown fields and risks misinterpreting results.
Error handling lacks recovery guidance. Tools return domain errors but do not tell LLMs what to do next (retry, ask user, call alternative tool). E.g., 'Unknown plan_id' should suggest 'Call get_aws_execution with a valid execution_id from a recent plan.'
No dry-run or confirmation step for destructive operations. execute_aws_plan with WRITE/REVERSIBLE risk requires approval_token but no mechanism to preview what will execute before approval. Agents cannot see the actual AWS CLI command that will run.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 64 | 2025-06-18+ | v2 |
Create an immutable, hashed execution plan for one AWS CLI operation (service, operation, args) across the selected targets. This never runs anything; it is the required first step before execute_aws_plan. The response includes the risk classification and requires_approval. If requires_approval is true (mutating, destructive, or unknown operations), you cannot execute the plan yourself: a human must run "awsmux approve <plan-id>" in their terminal and hand you the printed approval token, which you then pass to execute_aws_plan. read_only plans execute directly with no token. Plans expire one hour after creation. For read operations, ALWAYS put a server-side projection in args, e.g. ["--query", "Vpcs[].VpcId"], plus --filters where the service supports them: it shrinks every per-target result to just the fields you need, keeps the execution response small enough to return whole, and on large fleets is the difference between one round trip and many.
Parameter constraints not fully specified. 'concurrency' and 'timeout_s' in execute_aws_plan lack min/max bounds. 'limit' in get_aws_execution has no documented range. Unbounded integers let LLMs pass absurd values (concurrency=999999, timeout_s=2147483647).
Pagination not fully documented. get_aws_execution accepts offset/limit but does not specify max result count, whether offset is 0-indexed, or what happens when offset exceeds total. Large fleets could return thousands of rows, exhausting context.