# AWS MCP Servers

> AWS Labs' suite of MCP servers for docs, infrastructure and data

- Category: Agents & Automation / Workflow Automation
- Language: Python
- Licence: Apache-2.0
- Repository: https://github.com/awslabs/mcp
- Website: https://awslabs.github.io/mcp/
- Canonical page: https://ai-tldr.dev/tools/aws-mcp-servers/

## In short

AWS MCP Servers is AWS Labs' official collection of Model Context Protocol servers for working with AWS from an AI client. It sits in the Workflow Automation category of the Agents & Automation tools and is open-source, written in Python and licensed Apache-2.0. To get started: run a server.

## Overview

AWS MCP Servers is AWS Labs' official collection of Model Context Protocol servers for working with AWS from an AI client. Rather than one monolithic server, the repository publishes many focused ones — each a separate package you run on demand — so an agent only ever gets the surface you deliberately hand it.

The suite spans several areas. Infrastructure and deployment servers cover infrastructure-as-code, CloudFormation, CDK, EKS and ECS. Data and analytics servers cover DynamoDB, Aurora (PostgreSQL, MySQL and DSQL), DocumentDB, Neptune and Redshift. AI and machine-learning servers cover Bedrock, Kendra, Amazon Q and SageMaker. There are also developer-tool servers for IAM, CloudWatch and pricing analysis, integration servers for SNS/SQS, Step Functions and Location Services, and a healthcare and life-sciences group covering HealthOmics, HealthImaging and HealthLake.

The one most people start with is the AWS Documentation server, which gives an agent grounded access to current AWS docs — a direct answer to models confidently citing API shapes that changed. Servers are run with `uvx` straight from the package index, so there is nothing to clone, and they use your existing AWS credentials and profile configuration.

## What it does

- Many single-purpose servers rather than one broad one, so you scope an agent to exactly the AWS surface it needs
- AWS Documentation server for grounded, current answers about AWS APIs and services
- Infrastructure and deployment: IaC, CloudFormation, CDK, EKS and ECS
- Data and analytics: DynamoDB, Aurora PostgreSQL/MySQL/DSQL, DocumentDB, Neptune and Redshift
- AI and ML: Bedrock, Kendra, Amazon Q and SageMaker; plus IAM, CloudWatch and pricing analysis
- Healthcare and life sciences: HealthOmics, HealthImaging and HealthLake
- Run on demand with uvx — no clone or install step — using your existing AWS credentials

## Getting started

Every server follows the same pattern: run it with uvx by package name, then register that command in your MCP client. Standard AWS credentials and profile configuration apply.

1. Run a server

   Servers are published as awslabs.<server-name>. The documentation server is the usual starting point.

```bash
uvx awslabs.aws-documentation-mcp-server@latest
```

2. Register it with your MCP client

   For VS Code, add it to .vscode/mcp.json. Other clients take the same command and args in their own config file.

```json
{
  "command": "uvx",
  "args": ["awslabs.aws-documentation-mcp-server@latest"],
  "env": {
    "FASTMCP_LOG_LEVEL": "ERROR",
    "AWS_DOCUMENTATION_PARTITION": "aws"
  }
}
```

3. Add further servers as you need them

   Swap the package name for any other server in the suite — the install and configuration shape is identical, which is what makes running several side by side practical.

```bash
uvx awslabs.[server-name]@latest
```

## When to use it

- Reach for it when an agent keeps inventing AWS API shapes — the documentation server grounds it in the real docs
- Reach for it to let an assistant draft and inspect CDK or CloudFormation stacks against your actual account
- Reach for it to give an agent scoped read access to operational data in DynamoDB, Aurora or CloudWatch
- Reach for it when you want per-service isolation: one server per capability instead of one credential that opens everything