AWS MCP Server

The AWS MCP Server is an AWS-managed remote MCP server and the core component of the Agent Toolkit for AWS. It does not run locally; it runs as a hosted endpoint at AWS and is used through a regular AWS account.

Per the documentation, an agent can call any of 300+ AWS services through a single authenticated endpoint, run Python code against AWS services in an isolated sandbox with no access to the local filesystem, search and retrieve current AWS documentation, and pull in project-specific instructions via loadable "agent skills". Documentation search and skill retrieval work without AWS credentials; actual AWS API calls require authentication through your own AWS permissions (IAM).

AWS offers two authentication paths. With OAuth, a human authenticates in the browser, or an automated agent authenticates by requesting a token; this works with web clients (such as Claude.ai) and most IDE, terminal, or desktop clients without installing anything locally. With SigV4, you first sign in via the AWS CLI (aws login) and then use the separate MCP Proxy for AWS to sign requests with your own AWS credentials — per the documentation, this is the recommended path for terminal/IDE coding agents such as Claude Code, Kiro, or Codex, and the only way to switch between multiple AWS accounts in one session or to hide write-capable tools entirely via read-only mode.

The server is currently available in two regions: US East (N. Virginia) at https://aws-mcp.us-east-1.api.aws/mcp and Europe (Frankfurt) at https://aws-mcp.eu-central-1.api.aws/mcp.

Registering via OAuth in Claude Code:

claude mcp add aws-mcp https://aws-mcp.us-east-1.api.aws/mcp --transport http

Registering via SigV4 (e.g. Cursor, Claude Desktop) through the MCP Proxy for AWS:

{
  "mcpServers": {
    "aws-mcp": {
      "command": "uvx",
      "args": [
        "mcp-proxy-for-aws-cli@latest",
        "https://aws-mcp.us-east-1.api.aws/mcp",
        "--metadata", "AWS_REGION=us-west-2"
      ]
    }
  }
}

AWS explicitly recommends removing older, separate servers such as aws-api-mcp-server and aws-knowledge-mcp-server from client configuration to avoid tool conflicts, since the AWS MCP Server merges these capabilities and, per the documentation, adds extra IAM security controls.

Why one endpoint instead of many separate servers

Before the AWS MCP Server, teams wanting to reach several AWS services often had to run and configure multiple separate MCP servers in parallel. The central endpoint solves this by bundling over 300 services behind a single authenticated connection. For users, this means less configuration overhead and a single place for permission management through IAM, instead of maintaining access rights across several independent servers.

Who the server fits

The server is particularly useful for development teams that already actively use AWS for infrastructure, databases, or AI services and want to handle recurring cloud operations directly from their coding agent — for example debugging failed Lambda invocations, looking up current service limits, or running small analysis scripts in the isolated sandbox. For organizations with strict compliance requirements, the SigV4 path via the MCP Proxy for AWS is relevant because it fits cleanly into existing IAM roles and CloudTrail logging.

An AWS account. For OAuth, an MCP client with OAuth support is enough, and its IAM role/user needs the AWSMCPSignInOAuthAccessPolicy managed policy attached. For SigV4, you also need the AWS CLI (version 2.32.0 or later) and uv/uvx for the MCP Proxy for AWS.

For OAuth, attach the managed policy arn:aws:iam::aws:policy/AWSMCPSignInOAuthAccessPolicy to your IAM role or user, then configure the endpoint URL in your client (some clients need the ?oauth=initialize suffix). On the first tool call, the client opens a browser window for AWS sign-in; per the documentation, granted access tokens are valid for 1 hour and auto-refresh for up to 12 hours.

For SigV4, first install the AWS CLI, sign in with aws login (per the documentation this auto-rotates credentials every 15 minutes for sessions up to 12 hours), and verify with aws sts get-caller-identity. Then install uv and configure the MCP Proxy for AWS (mcp-proxy-for-aws-cli) via uvx in your client as shown in the example.

claude mcp add aws-mcp https://aws-mcp.us-east-1.api.aws/mcp --transport http

Two paths: OAuth (browser-based login, or token requests for automated agents, no local process required) or SigV4 via the AWS CLI plus the MCP Proxy for AWS, which signs requests with your own AWS credentials. Only SigV4 supports switching between multiple AWS accounts in one session.

Effective permissions exactly match those of the IAM role or user, or the OAuth session, in use — the server itself grants no additional rights. Depending on the assigned IAM permissions, read and write access to any of the 300+ supported AWS services is possible. Per AWS, access can additionally be restricted via IAM condition keys specific to the MCP server.

Requests and tool parameters are sent over HTTPS to the AWS-operated endpoint in the selected region. Responses can include resource data from any AWS services used, and are passed to the MCP client and its language model. Per the documentation, Python code runs in an isolated AWS sandbox with no access to the local filesystem. AWS logs usage via CloudWatch and CloudTrail.

Because the server can call any of the 300+ AWS services, an overly broad IAM role or a compromised OAuth token enables far-reaching actions in the AWS account, up to changes on production resources. Grant only minimal, task-scoped IAM permissions, use IAM condition keys for the MCP server where possible, enable read-only mode for analysis-only work with SigV4, and monitor CloudTrail logs for unusual activity.