AWS MCP Servers: Which One to Use

For most people, the answer is the AWS MCP Server: a managed, remote server hosted by AWS at one endpoint, which searches AWS documentation without sign-in and runs AWS API calls with your own IAM credentials. It is part of the Agent Toolkit for AWS, which AWS made generally available on April 30, 2026. AWS now recommends it over the two servers most older guides describe: the open-source AWS API MCP Server, which its README marks as superseded, and the AWS Knowledge MCP Server. The awslabs/mcp repository still has dozens of service-specific servers, for EKS, DynamoDB, CloudWatch, billing and more, and those are worth adding only when the general server is not enough. Whichever you choose, IAM decides what the agent can do.

The four families

1. The AWS MCP Server (managed, remote)

AWS describes the Agent Toolkit for AWS↗ (opens in a new tab) as four parts: the AWS MCP Server, agent skills, plugins for Claude Code and Codex, and rules files. The server runs at https://aws-mcp.us-east-1.api.aws/mcp, with a second endpoint in Europe (Frankfurt). Its tools fall into two groups:

• Knowledge tools, which need no AWS sign-in: aws___search_documentation, aws___read_documentation, aws___retrieve_skill for step-by-step AWS procedures, aws___list_regions and aws___get_regional_availability.
• API tools, which use your credentials: aws___run_script, which runs Python with AWS API access in a sandbox, aws___get_presigned_url for S3 uploads and downloads, and aws___get_tasks for polling long jobs.

A note on names: this server launched in preview under its own user guide, and AWS’s older “Agent SOPs” are now called skills. The awslabs README still labels it “in preview”, while the toolkit’s document history records general availability; go by the user guide.

2. The AWS API MCP Server (open source, local, superseded)

This is the server most 2025 tutorials install with uvx awslabs.aws-api-mcp-server@latest. It runs on your machine and exposes two tools, call_aws, which runs validated AWS CLI commands, and suggest_aws_commands. It has useful switches, READ_OPERATIONS_ONLY and REQUIRE_MUTATION_CONSENT, but the AWS API MCP Server README↗ (opens in a new tab) now opens by saying it is superseded by the AWS MCP Server and links a migration guide. Keep it only if you must run everything locally, and plan to move.

3. Knowledge and documentation servers

The AWS Knowledge MCP Server is a remote server at https://knowledge-mcp.global.api.aws, generally available and set up with a URL alone, no AWS credentials, with documentation search, regional availability and skills. The local AWS Documentation MCP Server does a smaller version of the same job. Both are fine for an agent that should only read about AWS. AWS’s setup guide suggests removing them when you move to the AWS MCP Server, whose knowledge tools overlap, to avoid duplicate tools confusing the agent.

4. Service-specific servers

The awslabs/mcp repository↗ (opens in a new tab) lists around sixty open-source servers built for one service or job. Examples include Amazon EKS and Amazon ECS, DynamoDB, Aurora PostgreSQL and MySQL, Redshift, CloudWatch and CloudTrail, Billing and Cost Management, IAM, the Serverless and IaC servers, and AWS Support. They give an agent deeper, purpose-built tools than a general API call, such as generating Kubernetes manifests or troubleshooting an ECS deployment. Check each README before relying on one: the Cloud Control API server, for example, is marked deprecated in favor of the IaC server, and AWS also offers managed versions of the EKS and ECS servers; the managed EKS MCP Server is still in preview.

Which one to use

• You want an agent that can look things up and act across AWS: the AWS MCP Server.
• You only want answers about AWS, with no access to your account: the AWS Knowledge MCP Server, or the AWS MCP Server without signing in.
• You need deep, service-specific tools, for example for EKS or a database: the AWS MCP Server plus that one service server. Add servers one at a time; every extra tool list costs context.
• You are already on the AWS API MCP Server: follow its migration guide to the AWS MCP Server.
• You work across several AWS accounts in one session, or need write tools hidden from the agent: the AWS MCP Server with SigV4 sign-in, described below.

IAM least privilege

The AWS MCP Server has no IAM actions of its own. AWS’s page on how the server works with IAM↗ (opens in a new tab) explains that it authenticates your request, adds two condition keys and forwards the call, and the target service then authorizes it against your existing policies. So the agent can do exactly what the signed-in identity can do. The preview-era actions aws-mcp:InvokeMcp, aws-mcp:CallReadOnlyTool and aws-mcp:CallReadWriteTool no longer have any effect; if a Deny statement relied on them, rewrite it with the new keys.

• aws:ViaAWSMCPService is true for any request that came through an AWS managed MCP server.
• aws:CalledViaAWSMCP names the server, such as aws-mcp.amazonaws.com, so you can treat the AWS MCP Server differently from the EKS or ECS ones.

That lets one role behave differently for a person and for an agent. This policy, adapted from AWS’s examples, lets the role read S3 but blocks deletes when the request comes through the AWS MCP Server:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowS3ReadOperations",
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:ListBucket"],
      "Resource": "*"
    },
    {
      "Sid": "DenyDeleteWhenAccessedViaMCP",
      "Effect": "Deny",
      "Action": ["s3:DeleteObject", "s3:DeleteBucket"],
      "Resource": "*",
      "Condition": {
        "StringEquals": { "aws:CalledViaAWSMCP": "aws-mcp.amazonaws.com" }
      }
    }
  ]
}

Narrow Resource to the buckets the agent needs. Beyond that, the usual IAM best practices↗ (opens in a new tab) apply: temporary credentials rather than long-term keys, least-privilege permissions, and a separate role, or account, for the agent rather than your administrator profile. CloudTrail logs every call, and the condition keys let you tell agent calls apart from direct ones.

Setup in Claude Code

There are three ways in. The simplest is AWS’s plugin, /plugin install aws-core@claude-plugins-official followed by /reload-plugins, which bundles the server configuration with a set of AWS skills. To add only the server, choose a sign-in method:

• OAuth: no local software. Attach the managed policy AWSMCPSignInOAuthAccessPolicy to your IAM user or role, add the server, and sign in through AWS Sign-in in the browser on first use. Access tokens last an hour and refresh for up to 12 hours.
• SigV4: sign in with the AWS CLI (version 2.32.0 or later supports aws login), install uv, and run the MCP Proxy for AWS locally. Choose this for several accounts in one session, a default region, or read-only mode, which OAuth does not offer.

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

# SigV4 through the MCP Proxy for AWS, write tools hidden
aws login
claude mcp add-json aws-mcp '{"type":"stdio","command":"uvx","args":["mcp-proxy-for-aws-cli@latest","https://aws-mcp.us-east-1.api.aws/mcp","--metadata","AWS_REGION=us-west-2","--read-only"]}'

# then, inside Claude Code
/mcp

The proxy’s --read-only flag hides tools that may need write permissions, and --profile takes several profiles so the agent can switch per call. AWS’s setup guide↗ (opens in a new tab) has the equivalent commands for Cursor, Claude Desktop, Codex, Kiro and Gemini CLI, and a table of common sign-in errors; an expired session token is the usual reason an agent stops using AWS tools. Test with a harmless prompt such as “What AWS Regions are available?”.

Keeping the work visible

CloudTrail tells you what an agent did in AWS. It does not tell you what it was asked to do, or what is still waiting. fenbs keeps that part: a board where each feature, enhancement or bug is a task with a note saying what and why, a plan, and a test status, in lanes To Do, Next Up, In Progress and Completed. Add it next to the AWS server with claude mcp add --transport http fenbs https://fenbs.ai/api/mcp, and the agent can read the task before it touches AWS and record the outcome after, with each change in History under its name. A standing rule such as “ask before changing anything in the production account” belongs on the Decisions and rules page, which every connected assistant reads first. fenbs is not an AWS tool and has no view of your account; it holds the list.