S3 MCP server

Two different questions bring people here. The first is which S3 MCP server to connect an agent to, and the short answer is that AWS does not publish one for buckets and objects, so the real choice is between a community server and a general AWS CLI bridge. The second question is the one that matters: why not just build this on S3 yourself?

S3 is not the weak option, and this page does not argue that it is. It argues that the distance between a bucket and a drive your agents can work in is a list of things you would end up building, and that the list is longer than it looks from outside. Every limit below links to AWS’s own documentation.

The three things people mean

1. The S3 Tables MCP server, which is not about files

AWS shipped this in July 2025 and it is the only S3-branded MCP server AWS publishes. It manages Apache Iceberg tables in S3 table buckets: create a table bucket, define namespaces, create and query tables with SQL, turn a CSV into a table, read the S3 Metadata Table. It is a data-lake tool and a good one.

It is not a way to hand an agent a bucket. If you went looking for “S3 MCP server” because you wanted an agent reading and writing objects at keys you choose, this server does not do that. Note also that write access is off unless you start it with --allow-write, and that AWS’s own page says misconfigured permissions or unverified agent actions “may result in data loss, failed operations, or unexpected LLM behavior”, and that if you do enable writes, “we recommend you take a backup of your data”.

2. The AWS API MCP server, which is every AWS command at once

AWS also publishes a general server that turns AWS CLI commands into tool calls, so an agent can run aws s3 cp or aws s3api put-object through it. It covers object storage the way it covers everything else, by covering everything else.

The warnings AWS attaches to it are worth reading before you connect it to a fleet. On the commands themselves: aws s3 sync “can overwrite entire directories without warning” and aws s3 cp “can overwrite existing files without confirmation”. On the deployment shape: “This MCP server is NOT designed for multi-tenant environments. Do not use this server to serve multiple users or tenants simultaneously.” There is a read-only mode and a consent prompt for mutating operations, and you should turn both on.

The structural point is that an agent holding this server holds your account, not a folder. Narrowing it to “the drafts prefix of one bucket” is IAM work you do outside the server, per agent.

3. Community servers

Several exist and they are what most people actually connect. txn2/mcp-s3 is a fair representative: eight tools covering s3_list_buckets, s3_list_objects, s3_get_object, s3_get_object_metadata, s3_put_object, s3_delete_object, s3_copy_object and s3_presign_url. It runs read-only by default, defaults to 10 MB on reads and 100 MB on writes with both configurable, and works against any S3-compatible endpoint rather than only AWS. Others such as samuraikun/aws-s3-mcp cover similar ground, and hosted gateways like Composio, Zapier MCP and Pipedream expose S3 through their own endpoints, which adds actions and adds a third party between your agent and your bucket.

What S3 already gives you

Skip this part and the rest of the page is unfair. A bucket is not a blank sheet, and three of the hard pieces are already there.

• Durability and scale you will not outgrow, at a price nothing else matches.
• Versioning. Turn it on and every overwrite keeps the previous object, a delete writes a delete marker instead of removing anything, and any earlier version can be restored.
• Conditional writes, which is the piece most people do not know about. Since 2024, PutObject, CopyObject and CompleteMultipartUpload accept an If-None-Match header for write-if-absent and an If-Match header carrying an ETag for write-if-unchanged. A mismatch fails with 412 Precondition Failed. That is a real compare-and-swap, the same primitive Layven exposes as expected_version. Anyone still telling you S3 has no concurrency control is working from old information.
• Prefix-scoped credentials. An IAM policy can restrict a key to one prefix of one bucket.

The pieces are there. What follows is what sits between the pieces and a drive.

What you would end up building

Restore is per object, and a bad agent run is not

Versioning restores one object to one earlier version, by copying that version over the current one. That covers the case where you know which file and which version, which is the case you are in when a human made the mistake.

An agent run that goes wrong does not touch one file. It touches the eleven it decided were related, over four minutes. Putting that back means knowing which objects changed in that window and which version each one had before it. AWS has published the architecture for that, and the shape of it is the point: EventBridge notifications into Kinesis Data Firehose, a Glue crawler over the delivered events, Athena queries to work out what changed, S3 Batch Operations to copy the old versions back, and Lambda to remove objects created after the moment you are restoring to. AWS’s own framing is that “performing consistent point-in-time restores for large datasets can be challenging”. Third-party tools such as s3pitr and bucket-restore exist because it is not a built-in feature.

None of it is hard, exactly. It is a project. It is also a project nobody schedules until the afternoon they need it to already be finished.

History is billed as whole copies, and versioning is one-way

From the versioning documentation: “Each version of an object is the entire object; it is not just a diff from the previous version. Thus, if you have three versions of an object stored, you are charged for three objects.”

A human editing a document produces a few versions a week and this never comes up. An agent rewriting a 2 MB working file forty times a day produces about 2.4 GB of history a month from that one file. Multiply by a tree and by a fleet and it becomes a line item somebody asks about.

The control is a lifecycle rule expiring noncurrent versions, which you write, tune and own, and which is the only thing standing between “history costs money forever” and “history is gone”. Note also that the switch is one-way: “After you version-enable a bucket, it can never return to an unversioned state.” You can suspend versioning. You cannot undo it.

The log names the credential, not the agent

Object-level activity is not recorded by default. CloudTrail logs management events out of the box, but GetObject and PutObject are data events, which you enable per bucket and which are priced at $0.10 per 100,000 delivered, with no free first copy of the kind management events get. The money is not the problem at agent volumes. The default is: until somebody turns this on, there is no record that an object was ever read or written.

Turn it on and what you get is the IAM principal that made the call. Point five agents at one access key and the log shows one principal five times. Telling them apart means five IAM identities, each with a policy, a rotation story and a revocation path. The default quota is 1,000 roles per account so you will not run out, but you are now operating an identity system for your agents.

And what you end up with is not something an agent can read. The AWS pattern for reading it is CloudTrail delivered to a bucket and queried with Athena. “Which agent last touched this file, and what did it look like before” is a SQL query against a log lake, not something the next agent in the chain can ask for itself.

There is no supported way to search inside objects

The in-place option used to be S3 Select. AWS closed it: “After careful consideration, we have made the decision to close new customer access to Amazon S3 Select and Amazon S3 Glacier Select, effective July 25, 2024.” Existing customers keep it. If you are standing up a bucket today, you do not have it, and S3 Object Lambda went the same way in November 2025.

AWS’s recommendations in its place are client-side filtering, meaning download the object and filter it wherever your code runs, or Athena over catalogued structured data. Athena is the right answer for a data lake and the wrong shape for “which of these notes mentions the migration plan”.

For an agent, client-side filtering is the expensive pattern. Ten candidate objects means ten GetObject calls, ten full bodies through the context window, and one useful line at the end of it. The narrower the thing being looked for, the worse the ratio.

Conditional writes are a primitive, not a workflow

Three things sit between If-Match and agents safely sharing a tree.

There is no lock. Compare-and-swap tells an agent its write lost, after the work is done. It gives an agent no way to say “I am working on this file for the next few minutes, do not start”. For multi-step work, being told at the end is far more expensive than being told at the beginning.

Large writes lose to small ones. A caveat in AWS’s own documentation lands exactly on agent workloads: conditional writes “do not consider any in-progress multipart uploads”. A small conditional PutObject that lands during a long multipart upload makes the eventual CompleteMultipartUpload fail with 412, and recovering from that means starting the whole multipart upload again from CreateMultipartUpload.

Nothing sends the header for you. Conditional writes only protect anything if every client opts in on every write. Bucket policies can enforce it, which is another policy to write. Otherwise it is on each MCP server to send the header, and most of the community ones do not expose it at all.

You are on call for the MCP server

Whichever server you connect, somebody runs it, holds the AWS credentials it uses, picks the size caps, decides whether write mode is on, and updates it when the MCP specification moves. With a community server that somebody is you, and the failure mode is an agent fleet that stops working on a Tuesday for a reason nobody owns.

When S3 is the right answer

Often, and this is not a rhetorical concession: Layven stores its own blobs in an S3 bucket. Object storage is the correct substrate. The only question is what sits in front of it.

Connect an agent straight to a bucket when:

• The data already lives there and your pipelines read it there. Do not move it.
• The agent reads far more than it writes. Nothing above bites a reader.
• One agent, or agents on clearly separate prefixes, so nothing races.
• The objects are large: archives, media, datasets, model artefacts. Layven caps a single file at 1 GiB and does no tiering to Glacier.
• The work is analytical rather than editorial. S3 Tables and Athena exist for that and Layven has no answer to them.
• You already have the AWS muscle. If there is an IAM story, CloudTrail wired to something that reads it, and a Terraform module for buckets, the list above is a week rather than a quarter, and you should probably just do it.

If that is your situation, pick a community server, turn versioning on, and stop reading. You do not have a problem to solve.

When you need a drive built for agents

The other shape of work is several agents writing to the same tree, repeatedly, without a person between each pass. Shared plans and notes, datasets transformed in place, scratch state that outlives one session, context handed from one agent to the next. There the items above stop being separate chores and start compounding: the restore you need is across files, the audit you need names agents rather than keys, and the search you need returns lines rather than objects.

Layven is a drive for that case, built on the same object storage, with the layer above it already written.

The honest trade runs both ways. A raw bucket is cheaper per byte, has no file-size ceiling, tiers to Glacier and sits inside the account your infrastructure already lives in. Layven does none of that. Layven holds what your agents are working on, which is a smaller set of bytes with much harder requirements. Plenty of fleets run both, which is fine, because an agent can hold a bucket and a drive at the same time.

Next

Connecting Layven takes about two minutes in any client: Claude, Claude Code, Cursor, ChatGPT, or any other MCP client. If a managed drive is also on the table, the same treatment of Google Drive MCP covers a server that cannot edit an existing file at all, and Dropbox MCP covers a much fuller one with a 5 MB ceiling.