Because OpenDAL sits underneath, adding a second or third backend is a block of environment variables rather than another MCP server in your config, and the model only ever learns one address shape. The surface is deliberately narrow — listing and reading — so this is a retrieval path, not a way to write or move objects around.
An MCP server built on Apache OpenDAL, which normalises dozens of storage services behind one interface. You give each service an alias in environment variables, and afterwards every file is addressed as `alias://path`, whichever cloud it lives in. It lists directories and reads file contents, detecting text versus binary automatically.
- Files and directories listed from any configured storage service — the `list` tool
- File contents read back with automatic text/binary detection — the `read` tool
- One address scheme across backends: configure an S3 service under the alias `mys3` and then use `mys3://path/to/file`
- Access to S3, Azure Blob Storage, Google Cloud Storage and the rest of OpenDAL's service list without a separate server per provider
- Configuration entirely through environment variables, with a `.env` file also loaded automatically
Whatever credentials each backend needs, supplied as prefixed environment variables. Each service takes an alias and its own settings — for an S3 service aliased `mys3` that is `OPENDAL_MYS3_TYPE=s3`, `OPENDAL_MYS3_BUCKET`, `OPENDAL_MYS3_REGION`, `OPENDAL_MYS3_ENDPOINT`, `OPENDAL_MYS3_ACCESS_KEY_ID` and `OPENDAL_MYS3_SECRET_ACCESS_KEY`. Install with `pip install mcp-server-opendal`; the client config runs it as `uvx mcp-server-opendal`, so `uv` must be on the machine. The pyproject publishes the `mcp-server-opendal` entry point. It reads a `.env` file if one is present.
One command plus a key — uvx mcp-server-opendal, then supply credentials