Azure Blob Storage
Azure Blob Storage: containers and blobs, uploads and downloads, tiers and leases, plus SAS URLs minted from the account key.
About
Azure Blob Storage ships in the w6w first-party pack. It declares 14 actions, 2 health checks, and the host runs its code in a sandbox that never sees the credential.
- App id
io.w6w.azure-blob- Version
- 0.1.1
- Author
- w6w
- Licence
- MIT
- Categories
- Storage · DevOps & Infrastructure
Overview
Azure Blob Storage covers containers and blobs: list, upload, download, copy and delete, plus tier changes between Hot, Cool, Cold and Archive and metadata management. It completes the pack’s object-storage set alongside S3 and Google Cloud Storage, for workflows that already have data landing in an Azure storage account.
Distinctive here is a real lease — an exclusive lock on a blob, unlike the optimistic-concurrency-only pattern S3 and Cloud Storage offer — useful for a read-modify-write sequence that would otherwise lose a race. Container deletion counts the blobs it will remove and requires that number to be acknowledged before it proceeds, since Azure deletes a container and everything inside it in one irreversible call.
Blob tiering exposes what each move commits you to: moving into Cool, Cold or Archive comes with a minimum retention period, and an Archive-tier blob is offline until a rehydration completes, not just slow. The app authenticates with the account’s shared key and does not mint SAS URLs, a limitation of what that signature needs rather than a missing feature.
Build with Azure Blob Storage
Three routes to the same 14 actions. The Workflow tab is generated from Azure Blob Storage's own manifest and carries its real ids, so it is copy-pasteable; the Code and CLI examples are the same call for any action on any app, so every app-specific value in them is a blank you fill in.
Copy or move a blob
blob-copy Copy a blob, optionally deleting the source — which is what a rename is, because there is no move. The copy is ASYNCHRONOUS: the destination exists immediately and its contents may not be there yet.
Delete a blob
blob-delete Remove a blob. A blob with SNAPSHOTS refuses to be deleted until you say what happens to them. Whether the delete is reversible depends on the container's soft-delete policy — this reads it and says which.
Download a blob
blob-download Read a blob's contents as text. GET is the contents and HEAD is the properties, at the same URL — no `alt=media` equivalent. An ARCHIVE-tier blob answers 409 rather than reading slowly.
Get blob properties
blob-get A blob's size, type, tier, lease state and metadata — all from response HEADERS, with an empty body. An ARCHIVE-tier blob cannot be read until it is rehydrated, which takes hours.
Lease a blob
blob-lease Take, renew, release or break an exclusive lock on a blob — a real lock, which S3 and Cloud Storage do not have. Losing the lease id leaves the blob locked for the rest of its duration, which is why infinite leases are not offered here.
List blobs
blob-list List a container's blobs. With a delimiter, subfolders come back as separate <BlobPrefix> elements. Snapshots, versions, soft-deleted and UNCOMMITTED blobs are all billed and all hidden unless asked for.
Set blob metadata
blob-metadata-set Replace a blob's custom metadata — the WHOLE set, with no merge, and an empty call clears it. Names must be C# identifiers (a hyphen is rejected) and their case is lowercased on the way back.
Change a blob's tier
blob-set-tier Move a blob between Hot, Cool, Cold and Archive. Archive makes it UNREADABLE until rehydrated, which takes up to 15 hours, and every move restarts the destination tier's minimum billed duration.
Restore a deleted blob
blob-undelete Bring back a soft-deleted blob and all its soft-deleted snapshots — by NAME, with no version to name. Only works inside the retention window, and only if the account has a soft-delete policy at all.
Upload a blob
blob-upload Write a block blob from text. This OVERWRITES an existing name and returns 201 — use `ifNotExists`, or an ETag, to make a conflicting write fail with 412 instead. A blob's TYPE is fixed at creation.
Create a container
container-create Create a container, PRIVATE by default. `blob` access makes any known URL readable without a credential; `container` access lets anyone list and read everything — both are gated here.
Delete a container
container-delete Delete a container AND every blob in it — Azure does not require it to be empty, unlike S3 or Cloud Storage. The name cannot be reused for at least 30 seconds afterwards.
Get container properties
container-get A container's access level, lease state and immutability. An immutability policy or legal hold makes its blobs undeletable by ANYONE, including the account key — the only thing in Azure Storage that outranks it.
List containers
container-list The account's containers, counting those with PUBLIC access — `blob` makes any known URL readable, `container` makes the whole thing listable, and neither is an error anywhere.
A workflow step names the app and the action, and the editor fills in the
connection when you pick one. This is the Step shape from the
workflow spec, carrying Azure Blob Storage's real ids.
{
"manifestVersion": "2",
"name": "azure-blob-example",
"steps": [
{
"id": "blob-copy",
"uses": {
"app": "io.w6w.azure-blob",
"action": "blob-copy",
"connection": "conn_YOUR_CONNECTION_ID"
},
"with": {
"sourceContainer": "<sourceContainer>",
"sourceBlob": "<sourceBlob>",
"destinationBlob": "<destinationBlob>"
}
}
]
}Here are some of the things you can do
-
Copy or move a blob
performblob-copy -
Download a blob
readblob-download -
Get blob properties
readblob-get -
Lease a blob
performblob-lease -
List blobs
searchblob-list
+9 more actions available
Every app-specific value here is a blank you have to fill in. An
app action is reached through the connection that authenticates it, so the
address is a connection id, not the app id — and connections belong to your account,
so a public page cannot know yours. Create one for Azure Blob Storage, then fill in
the three blanks: conn_YOUR_CONNECTION_ID, the action key, and the
parameters that action declares. The call itself is real — the shape is transcribed
from the studio's own snippet builder, which prints the same kind of blanks — but
nothing in it is specific to Azure Blob Storage. The Workflow tab is where this app's
real ids are.
npm install @w6w/sdkyarn add @w6w/sdkpnpm add @w6w/sdkdeno add npm:@w6w/sdkimport { W6wClient, isActionRun } from "@w6w/sdk";
// Reads W6W_BASE_URL and W6W_TOKEN from the environment when omitted.
const client = new W6wClient();
const envelope = await client.run({
urn: "conn_YOUR_CONNECTION_ID",
action: "blob-copy",
payload: {
sourceContainer: "<value>",
sourceBlob: "<value>",
// destinationContainer: "<value>",
destinationBlob: "<value>",
// deleteSource: "<value>",
},
});
if (isActionRun(envelope)) console.log(envelope.value);npm install -g @w6w/cliw6w run conn_YOUR_CONNECTION_ID --action blob-copy --payload '{"sourceContainer":"<value>","sourceBlob":"<value>","destinationBlob":"<value>"}'Give an AI agent Azure Blob Storage — without giving it Azure Blob Storage's credentials. One MCP endpoint exposes every app, function and workflow the caller is entitled to, as tools it can discover and run. Access is granted per team while we onboard.
One tool call{
"name": "w6w_invoke",
"arguments": {
"ref": "app:io.w6w.azure-blob#blob-copy",
"input": {
"sourceContainer": "<sourceContainer>",
"sourceBlob": "<sourceBlob>",
"destinationBlob": "<destinationBlob>"
}
}
}
Every tool names its target with a single ref. The
app: form above doesn't name a connection at all — the
host resolves which of the caller's Azure Blob Storage connections to sign
with, and refuses rather than guesses when the answer is ambiguous.
What the agent gets
Credentials it can't read
The token is attached host-side, at the moment of the call. It is never a tool argument, never in the model's context, and never in a transcript — so a prompt injection has nothing to exfiltrate.
A tool surface scoped to the caller
Tools are derived per end user from what that person has actually connected and is entitled to — not one shared bot identity carrying the union of everyone's access.
A durable workflow in one call
Multi-step work runs on the workflow engine and returns a run handle the agent can poll — retries, branching and state survive the conversation that started them.
Health-aware discovery
Azure Blob Storage's declared health checks are on the surface too, so an agent can tell "the vendor is down" from "your credential expired" before it burns a retry on either.
The MCP surface is part of the hosted platform. Azure Blob Storage itself is MIT, and the runtime that executes it is source-available (FSL).
Health checks
Azure Blob Storage declares its own checks, so its health is a property of the app rather than something the host guesses at.
Azure Storage status
Not checkable usefully. Azure publishes incident announcements as RSS PROSE with no per-service health field, and Storage health is per REGION and per account anyway — the `account` check answers that, and this could not.
Storage account reachable
Lists containers with this connection's key. Azure offers no unauthenticated probe, so this cannot fully separate an outage from a rotated key — it names which one a given failure looks like, including CLOCK DRIFT, which Azure reports as a permission error.