# Standalone Daedro S3 MCP connection

This operator integration selects the existing Go
[txn2/mcp-s3 v1.5.1](https://github.com/txn2/mcp-s3/tree/v1.5.1) under Apache-2.0.
The image is pinned by immutable digest in `manifest.json` and `launch.sh`.
It runs independently of Daedro services, databases and the Python runtime.
The upstream handshake identity remains `mcp-s3`; the client connection name is
`daedro-s3`. It is not a newly implemented Daedro storage engine.

Prepare the pinned image explicitly:

```sh
docker --context default pull ghcr.io/txn2/mcp-s3@sha256:c907ec59b4edd045c38d879d42fd117dfb3d396b61b2417243717fffb81bcc7d
```

Create a dedicated operator-owned mode0600 credential env file outside tracked
files. It contains only `AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY` and optionally
`AWS_SESSION_TOKEN`. Docker reads it as data; the launcher never executes it.
Do not pass another application's entire environment file to a third-party MCP.

Configure the MCP client to run `/bin/sh` with the absolute path of `launch.sh`.
Supply these launcher variables through the client's private environment:

| Variable | Purpose |
|---|---|
| `DAEDRO_S3_ENDPOINT` | Selected HTTPS S3-compatible endpoint |
| `DAEDRO_S3_REGION` | Storage signing region; default `us-east-1` |
| `DAEDRO_S3_ENV_FILE` | Absolute path to the dedicated private credential file |
| `DAEDRO_DOCKER_CONTEXT` | Explicit local Docker context; default `default` |
| `DAEDRO_S3_NETWORK` | Docker network; default `bridge` |

The local operator selects a real endpoint and credential scope; no installation
endpoint, bucket inventory, object content or key is shipped with the platform.
Credentials need only the selected bucket-list/list-object/get-object permissions.
If the account cannot list buckets, configure/use the bucket name supplied by its
operator directly rather than treating a denied list as invalid credentials.

Use the manifest's five-tool client allowlist. The upstream server also enforces
read-only mode, including against direct calls to its advertised write tools.
The upstream object-size admission limit is configured to1MB. Concurrent object
mutation and strict streaming byte ceilings were not exercised by this connection
check. Logging and audit output are disabled in this
selected profile. The container has a read-only filesystem, no host mounts,
dropped capabilities, resource caps and a non-root upstream user. Secrets are
runtime environment values; the Docker operator can inspect its own containers.

The launcher never pulls at startup or changes bucket/object data. It fails if
the pinned image or required configuration is unavailable. Reconnect by starting
another stdio session. Remove the client entry to disconnect; no data migration
or bucket deletion is involved. Changing image versions requires another explicit
pull and connection/compatibility check.

This connection does not turn `data.corpus@1` or `mediaobjects` into S3-backed
storage and does not establish cloud write/bulk-transfer/recovery guarantees.
Those are separately versioned storage contracts. Keep deployment-specific
connection results and credentials outside tracked platform files.