AWS S3 MCP Server: IAM-Scoped Access for AI
What it is: AWS Labs — AWS's own GitHub org for previewed, labs-stage tooling — maintains a growing monorepo of MCP servers at awslabs/mcp, covering many AWS services. S3 access is available through it, either via a dedicated S3-focused server or the more general AWS API MCP server that can call any AWS service's API (including S3) from natural-language requests. This catalog changes frequently as AWS adds and renames servers, so rather than name one specific package that may be stale by the time you read this, check the repo's current server list before installing.
Quick answer: Find the current S3-related server in the awslabs/mcp catalog, install it with uvx per its own README, and authenticate with standard AWS credentials (an IAM role or profile) scoped to specific buckets — never the account's admin credentials. Treat this the same way you'd treat handing an agent an AWS access key: the IAM policy attached to it is the entire safety boundary.
Why it matters for data work
S3 is the default landing zone for a huge share of raw and processed data — exports, Parquet files, data lake tables, backups. An agent that can list, read, and describe objects in a bucket can answer "how large did last month's export get" or pull a specific file's contents into an analysis without you opening the AWS console or running aws s3 commands by hand.
Install & configure
AWS Labs servers generally authenticate through the standard AWS credential chain — environment variables, a named profile, or an IAM role if running on AWS infrastructure — rather than a custom token:
# Claude Code — pattern; confirm the exact package name in the awslabs/mcp repo
claude mcp add aws-s3 -e AWS_PROFILE=my-scoped-profile -- uvx <awslabs-package-name>
// Claude Desktop / Cursor config
{
"mcpServers": {
"aws-s3": {
"command": "uvx",
"args": ["<awslabs-package-name>"],
"env": {
"AWS_PROFILE": "my-scoped-profile",
"AWS_REGION": "us-east-1"
}
}
}
}
Set up the named profile in ~/.aws/credentials ahead of time, pointing at an IAM user or role whose policy is scoped the way you want — don't reuse your default AWS CLI profile if that profile has broad account access.
IAM role scoped to one bucket, or account-wide access?
This is the decision that matters most, and it's made in IAM, not in the MCP config. A policy like the one below limits the agent to a single bucket and, optionally, a prefix within it — the agent literally cannot see or touch anything else in the account, regardless of what the model tries:
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": ["s3:GetObject", "s3:ListBucket"],
"Resource": [
"arn:aws:s3:::my-analytics-bucket",
"arn:aws:s3:::my-analytics-bucket/exports/*"
]
}]
}
Start read-only (s3:GetObject, s3:ListBucket) and add s3:PutObject only when the agent genuinely needs to write results back — never grant s3:* or attach a broad managed policy like AmazonS3FullAccess to a credential an agent uses.
How do I keep it safe?
The MCP server itself has no independent access control — whatever the underlying AWS credential can do, the agent can do. Use a dedicated IAM user or role created specifically for this integration (never your personal AWS credentials), keep it bucket- and prefix-scoped per the policy above, and avoid pointing it at any bucket holding production backups, credentials, or PII unless read-only access has been deliberately reviewed. Rotate access keys the same way you would for any other automated integration.
Troubleshooting
Most problems trace back to IAM, not the server:
- AccessDenied: the attached IAM policy doesn't grant the specific action/resource being called — check the policy against the exact bucket ARN and action.
- Credentials not found: the
AWS_PROFILEdoesn't exist in~/.aws/credentials, or the environment running the server can't see that file (common with containerized setups — mount or pass credentials explicitly). - Region mismatch errors: S3 bucket operations are region-specific for some calls; set
AWS_REGIONto match the bucket's actual region. - Package name changed: AWS Labs renames and reorganizes servers as the catalog grows — re-check
awslabs/mcpif a previously-working install command stops resolving.
Author & links
Author: AWS Labs (AWS-affiliated; labs/preview stage, not a GA AWS product)
Repo: github.com/awslabs/mcp
License: Apache-2.0
Related skills
For warehouse-scale analytics on top of data that often lives in S3, see the Snowflake MCP server, BigQuery MCP server, or Databricks MCP server. For local file access with the same read/write caution, see the Filesystem MCP server.
← Back to MCP Servers