At a glance
- Availability: Experimental (how to enable).
- Auth: OAuth 2.0.
- Connection: A user authorizes the connection in the provider’s consent screen.
- Scopes:
https://storage.azure.com/user_impersonation,offline_access. - Docs: https://learn.microsoft.com/en-us/rest/api/storageservices/authorize-with-azure-active-directory
Credentials
Set these per environment. See Connect an integration. With a managed OAuth app, Connect works without these variables; set them to use your own OAuth app instead.Setup
- Create a storage account: In https://portal.azure.com (a free Azure account includes credit and free-tier storage) create a Storage account, then create a container and upload a small test blob. Note the storage account name - it forms the request host https://{accountName}.blob.core.windows.net.
- Register a Microsoft Entra application: Open https://portal.azure.com/#view/Microsoft_AAD_RegisteredApps/ApplicationsListBlade, register an app (supported account types: accounts in any organizational directory and personal accounts work for the common endpoint), and add your callback URL as a Web redirect URI. Create a client secret. Store the Application (client) ID as MICROSOFT_CLIENT_ID and the secret as MICROSOFT_CLIENT_SECRET.
- Add the Azure Storage delegated permission: In the app registration, go to API permissions, click Add a permission, choose Azure Storage, and add the delegated user_impersonation permission.
- Grant the signed-in user a data role: OAuth tokens act on behalf of the user, so the user also needs RBAC access to blob data: on the storage account, assign Storage Blob Data Reader (read-only) or Storage Blob Data Contributor (read/write/delete) to the user under Access control (IAM). Role assignments can take a few minutes to propagate.
- Set the default account name: Optionally set AZURE_STORAGE_ACCOUNT to your storage account name so agents know which account to target; the account name is passed as the accountName parameter on every tool call.
- The Blob service REST API returns XML, not JSON - listing responses are <EnumerationResults> documents and errors are <Error> documents.
- Every OAuth-authorized request must include an x-ms-version header (2017-11-09 or later); tools default to 2026-04-06, the latest fully deployed service version.
- Entra ID authorization is two-layered: the OAuth scope (user_impersonation) only delegates the user’s rights, and the user must separately hold a Storage Blob Data RBAC role on the account or container.
- The host is account-specific (https://{accountName}.blob.core.windows.net), so every tool takes the storage account name as a parameter.
Tools
| Tool | Access | Description |
|---|---|---|
| List Containers | Read | List blob containers in a storage account; the response is XML (EnumerationResults), not JSON |
| List Blobs | Read | List blobs in a container, optionally filtered by name prefix; the response is XML (EnumerationResults), not JSON |
| Download Blob | Read | Download a blob’s content (Get Blob); blob properties are returned as x-ms-* response headers |
| Upload Blob | Write | Create or overwrite a block blob with the given content (Put Blob) |
| Delete Blob | Write | Delete a blob from a container (Delete Blob); errors are returned as XML |
| Create Container | Write | Create a new blob container in the storage account (Create Container); fails with 409 if a container with the same name already exists |
| Copy Blob | Write | Server-side copy of a blob to a destination within the storage account (Copy Blob) - no download/re-upload needed; returns 202 with x-ms-copy-status ‘success’ or ‘pending’ (poll the destination blob until the copy finishes) |
Example prompts
- List the blobs in one of my Azure Storage containers and summarize what’s stored there.
- Download a blob from my Azure Storage container and summarize its contents.