AWS API MCP Server

The server runs every AWS call with the operator's ambient credentials (the boto3 default chain or a configured profile), and the model may switch to any other locally configured profile with --profile. By default there is no authorization layer: every operation, including IAM changes to the server's own identity, is allowed. An opt-in read-only mode maps each request to AWS's own Service Authorization data and denies writes, failing closed on unknown services or fetch errors, but it still lets the model mint EKS, ECR and RDS tokens and pick a more privileged profile. IAM policy on the operator's credentials is the only real bound.

Everything goes through one call_aws tool that mixes reads and writes; by default it is simply annotated destructive, so the host must gate every call because it can't tell reads from writes. The server offers an opt-in consent mode that, for every operation AWS classes as a write, shows the user the exact CLI command through MCP elicitation and refuses if the client can't ask. It is off by default, and when it is off every AWS action, including deletes and terminations, runs without any server-side confirmation. AWS actions cannot be rolled back by the server.

call_aws is a general tool: any AWS API in any region with the operator's credentials. Inputs are parsed as AWS CLI syntax, not passed to a shell. The parser checks parameters against the service schema, rejects --debug, --no-verify-ssl and --no-sign-request, only allows loopback --endpoint-url values, and limits CLI customizations to an allowlist that spawns no subprocesses. Local file arguments are confined by default to a working directory using resolved paths. Files referenced indirectly (for example artefacts listed inside a CloudFormation template) are not confined, and nothing limits which AWS resources or quantities a call may touch.

The server has no local shell or eval: model output is parsed into AWS API calls, and the CLI customizations it allows spawn no subprocesses. It does, however, forward model-written code for execution in the operator's AWS account (SSM RunCommand shell scripts, CloudFormation deploys, Lambda code, EC2 user data), all allowed by default with no isolation boundary and the operator's credentials. The opt-in unrestricted file-access mode also does not confine local execution.

The server returns AWS data, including content anyone with write access to the account's resources can control (S3 objects, log events, tags, queue messages), as structured JSON with the command, service, operation and region attached, but with nothing marking it as untrusted. In the default configuration a hijacked model can both read sensitive data and act on it: copy data to an external bucket or topic, mint credentials, or delete resources, all without a human step. The opt-in read-only and consent modes narrow this, but they are off by default.

The server keeps no memory and loads no context from the working directory. Its only configuration files are environment variables and a user-scope policy file in ~/.aws/aws-api-mcp, which the model cannot write in the default working-directory file mode because of resolved-path containment. Opt-in unrestricted file access would let the model overwrite that file.

The server loads no plugins, MCP servers, packages or model files at runtime. Remote data it fetches (AWS service-reference documents and command suggestions from an AWS endpoint) is data, not code. Opt-in agent scripts are markdown read from a directory the operator chooses. The AWS CLI's own [plugins] config section in ~/.aws/config is user scope and outside this server's code.

The server never puts its own AWS keys into model context or logs, and its execution log deliberately omits command parameters. But credentials are held in a plain model with no masking, the suggest tool logs the user's query verbatim, and AWS responses go to the model unredacted, including secrets the model asks for (Secrets Manager values, SSM SecureString parameters, new IAM access keys, which are allowed by default). Telemetry is on by default. It sends no content, only the MCP client name, version and configuration flags in the AWS User-Agent.

The server writes a loguru log to ~/.aws/aws-api-mcp/aws-api-mcp-server.log (10 MB rotation, 7-day retention), outside the working directory. Each executed command is recorded only as service and operation; parameters are deliberately left out. Policy denials and user consent decisions go back to the client as errors, not into the server log. Nothing records which user or client made a call, and nothing protects the log from tampering, so an incident can be traced to operations but not to the exact resources touched or who approved them.

The server caps a batch at 20 commands and sets 10-second connect and 60-second read timeouts with three retries on each AWS call. Pagination is unbounded unless the caller passes max_results, and --region * multiplies each command across every enabled region. There is no rate limit, no session budget, no limit on how many resources a call creates, and no way to cancel an in-flight call.