AWS MCP Server

What AWS MCP Server does

AWS MCP Server gives an MCP client access to AWS through the machine's AWS CLI configuration. Its general-purpose aws_call tool accepts a service, operation, and JSON parameters, allowing one interface to reach AWS API operations known by the installed CLI. The server also supports AWS Cloud Control API resources, CloudWatch logs and metrics, Lambda invocation, IAM policy simulation, STS role assumption, live AWS documentation, and fan-out across regions or accounts.

Authentication is designed around AWS profiles and SSO. The server can inspect the active identity, start a device-code login, wait for completion, and refresh an SSO token before a long workflow. Temporary credentials from role assumption can be stored under a named profile for later calls, while multi-account operations keep assumed credentials in memory for the duration of the operation.

How it works

The server runs locally and delegates AWS operations to the installed aws CLI. Session-level profile and region overrides can be set, inspected, or cleared independently of environment defaults. Calls can also provide their own profile or region where supported.

For large or repeated reads, aws_paginate returns a cursor for the next page, while aws_multi_region runs one operation across several regions in parallel. aws_multi_account assumes the same role in multiple twelve-digit accounts and reports successes and failures separately. aws_script can combine supported helpers such as API calls, pagination, resource operations, documentation access, and metrics queries in one JavaScript execution.

Cloud Control create, update, and delete operations are asynchronous by default. The server returns a request token for polling, or can wait for completion. Resource updates use RFC 6902 JSON Patch, and aws_resource_diff previews supported changes without sending a mutation.

Setup and configuration

Install the package as an MCP command using the npm package runner:

{
  "command": "npx",
  "args": ["-y", "@yawlabs/aws-mcp"]
}

The process uses the AWS CLI, its configured profiles, and its credential stores. AWS_PROFILE and AWS_REGION can provide environment-level defaults; session tools can override either value for subsequent calls. SSO profiles should be configured through the AWS CLI before the server needs to use them. The aws_list_profiles tool reports configured profiles and available SSO metadata.

Tools and capabilities

• Call arbitrary AWS CLI API operations with structured JSON parameters.
• Page list and describe operations, including query-based response projection.
• Read, create, update, delete, diff, and monitor Cloud Control API resources.
• Query CloudWatch Logs Insights, tail recent log events, and retrieve CloudWatch metric series.
• Invoke Lambda synchronously with its response payload and decoded log tail.
• Simulate IAM permissions before attempting a potentially failing operation.
• Assume roles, inspect identities, manage session defaults, and complete SSO device-code login.
• Run the same operation across multiple regions or accounts.
• Search AWS documentation and retrieve pages as paginated markdown.

Limitations and notes

aws_call is intended for API operations that accept the CLI's JSON input mechanism. Hand-written CLI commands such as S3 copy and sync, operations that write response bodies to output files, and some streaming operations require another tool or a shell. The server provides specific alternatives for Lambda invocation and CloudWatch logs where available.

Cloud Control coverage depends on the resource type's schema and supported verbs. Its create, update, and delete calls can be destructive, so identifiers should be checked before execution. Results are subject to a 5 MB output cap in several fan-out and pagination scenarios.

An SSO refresh returning status: "ok" only reports the cache at that moment; it does not reserve the token for the workflow. aws_logs_query can incur CloudWatch Logs Insights scanning charges, and its query continues running after a client-side timeout. aws_script runs in the server process and is not a security sandbox, so only trusted script text should be executed.