The tool list goes deeper than upload-and-list: blobs, CAR shards and upload DAGs are each addressable, so removing an upload listing and removing the bytes under it are separate decisions — w3_can_upload_rm states outright that it leaves the blobs and shards in place. Worth planning around: agent state can be ephemeral, in Docker for instance, so authorization needs re-checking after a reconnect, and w3_reset drops every proof and delegation behind an explicit confirmation argument.
A wrapper over the w3 command line for storacha.network, with 35 tools covering login, spaces, uploads, delegations and the blob and CAR layer beneath them.
- Agent authorization: log in with the configured email, confirm which accounts the agent is authorized for, and select the space later calls act on
- Uploads from absolute paths, listed, opened by CID, and removed by root CID
- Delegations issued to an audience DID with named capabilities and an output file, listed, revoked, and claimed on the receiving side from a proof
- The layer under an upload addressed on its own: blobs added and removed by base58btc multihash, CAR shards stored and removed by CID, and upload DAGs registered from a root CID and its shard CIDs
- Account state you can read: the plan on an account, a storage usage report per space, and Filecoin deal information for a Piece CID
- UCAN-HTTP bridge tokens generated with capabilities and an expiry, and fresh ed25519 key pairs printed on request
W3_LOGIN_EMAIL, a storacha.network account, and access to that mailbox — w3_login waits on an email confirmation that has to be clicked before the other tools work. A space also has to exist already: w3_space_create cannot run through MCP because of its interactive recovery-key prompt, so it is created in a terminal first. Files live on the machine running the server and are addressed by absolute path.
One command — npx -y mcp-ipfs