# Backblaze B2 MCP Server [Health: Active]

**Category:** 📂 File Systems  
**Repository:** https://github.com/backblaze-labs/b2-mcp  
**GitHub Stars:** 46  
**npm Downloads (last month):** 0  
**Views:** 0  
**Installs:** 0  
**Upvotes:** 0  
**Directory Page:** https://allmcps.com/mcp/backblaze-b2-mcp-server

## Description
Operate Backblaze B2 buckets, files, keys, Object Lock, and S3-compatible storage.

## Tools
Capabilities this server exposes over MCP:

- **b2_authorize_account** — Authorize with B2 and return account info including accountId, apiUrl, and downloadUrl. The server handles authorization automatically, but this tool is useful for verifying credentials and retrieving account details.
- **b2_create_bucket** — Create a persistent B2 bucket with optional metadata, CORS, lifecycle, default encryption, and Object Lock enablement. Use for initial provisioning with a key that has writeBuckets; use b2_update_bucket for later settings changes and s3_head_bucket to check S3 reachability. Bucket names are globally unique, case-insensitive, 6-63 characters, letters/digits/hyphens/periods, and cannot start with 'b2-', begin/end with a period, contain '..', or look like an IPv4 address. Because names are unique across all of B2, requesting a name already in use (by this or any other account) fails with a duplicate-name error instead of returning the existing bucket; reuse the existing bucket only if it belongs to your own account, otherwise choose a different globally unique name.
- **b2_create_group_member** — Create a Backblaze account for a new Partner group member. In file sink mode, the one-time application key secret is written to the configured out-of-band secret sink and the MCP response contains only redacted metadata plus a secretSink pointer. In inline mode, the secret is returned with an explicit warning.
- **b2_create_key** — Create a B2 application key and route its one-time secret through the configured secret sink. Use for least-privilege scoped credentials; use b2_list_keys to inspect existing keys and b2_delete_key to revoke retired keys. Requires writeKeys, idempotencyKey, and destructive confirmation by policy. File sink mode returns redacted metadata plus a secretSink pointer; inline mode returns the secret only when explicitly enabled. Policy refuses key-management grants and unscoped write/delete grants unless explicit environment overrides are enabled; when B2_MAX_KEY_DURATION_SECONDS is set, it also refuses non-expiring keys or durations above that limit.
- **b2_delete_bucket** — Delete a B2 bucket. The bucket must be empty — all files and file versions must be deleted first.
- **b2_delete_key** — Permanently delete a B2 application key. Use b2_list_keys first to verify applicationKeyId, keyName, capabilities, and dependent systems; use b2_create_key before deletion when rotating credentials. Requires deleteKeys and destructive confirmation by policy. The key secret cannot be recovered, and anything still using the deleted key loses access immediately.
- **b2_eject_group_member** — Eject a member from a Group. The account is NOT deleted — just removed (the member resets their password on next login). Optionally change their email on eject. Cannot be re-added via API (only the Group Management page).
- **b2_get_bucket_notification_rules** — Read the B2 event-notification webhook rules for a bucket. Use before b2_set_bucket_notification_rules to diff or preserve existing rules, because set replaces the complete rule set. Requires readBucketNotifications or writeBucketNotifications, has no side effects, and redacts webhook URL host/path/query, HMAC secrets, and custom-header values in the MCP response.
- **b2_list_buckets** — List B2 buckets for the authorized account. Optionally filter by bucket ID, name, or type. When the key is bucket-scoped and no bucketId/bucketName filter is supplied, requests are automatically narrowed to the authorized bucket IDs. Returns bucket ID, name, type, CORS rules, and lifecycle rules for each bucket. Capped to `limit` buckets (default 100, max 1000) to keep the response small for accounts with many buckets; if more exist the result is truncated with total_bucket_count and a note — raise limit or filter to target specific buckets.
- **b2_list_group_members** — List active (ACCEPTED) Group members for a specific Group. Returns up to 1,000 members per call; use nextEmail for pagination. Includes B2 storage stats per member.
- **b2_list_groups** — List active Groups administered by a Group admin account. Returns up to 100 groups per call; use nextGroupId for pagination. Requires the account to be authorized for the Partner API.
- **b2_list_keys** — List the application keys associated with the B2 account. Does not return the actual key secrets — only key IDs, names, capabilities, and restrictions.
- **b2_list_largest_files** — List a bucket's largest objects by size via a live listing. For 'largest files', 'what's taking up space in <bucket>'. Give the bucket by name or bucketId; optional path prefix. Sorting by size requires a full listing, so on very large buckets the scan is bounded by max_scan and a time budget — it then returns the largest among the objects scanned with truncated=true; pass a prefix to focus on a subtree for a complete ranking. Returns name, size, and upload time — never contents.
- **b2_rank_egress_leaders** — Rank top egress (downloaded bytes) by account or bucket over a period — default month-to-date. For 'who's downloading the most', 'where is egress concentrated'. Returns leaders with each one's share of total egress, from the daily usage reports. Scope follows the caller's key. Needs Usage Reports enabled.
- **b2_report_usage_growth** — Rank accounts by how much STORED data grew or shrank between two points in time, from the daily B2 usage reports (uses stored_gb, the end-of-day snapshot). For 'which customers grew the most/least', 'who's moving data off'. Compares the latest snapshot against one month/quarter/year earlier and fetches only those two days, so it stays fast even on large report buckets. Returns the two dates compared and per-account start vs current GB and % growth (new accounts flagged). Scope follows the caller's key (a partner key sees all its sub-accounts). Needs Usage Reports enabled.
- **b2_reserve_trial_create_account** — Reserve and create a B2 Reserve trial account through the Partner API, returning a durable application key for the new account. Requires a Partner-entitled master key, and is a billable, irreversible account creation governed by the destructive-operation gate. Available only in explicit inline secret-sink mode because Reserve Trial has no provider-side recovery path if a file-sink write fails after account creation; the minted key is shown once, so capture it. Retries are not deduplicated server-side, so repeating the call can create another account regardless of idempotencyKey; verify whether the account already exists and reconcile before retrying. Use b2_create_group_member to add an account to an existing Partner group instead of provisioning a standalone trial.
- **b2_set_bucket_notification_rules** — Replace the complete B2 event-notification webhook rule set for a bucket. Use b2_get_bucket_notification_rules first and submit the full desired rule set; this is not a patch or append API. Requires writeBucketNotifications and destructive confirmation by policy. Each webhook URL must be a public HTTPS endpoint, and echoed URL details, HMAC secrets, and custom-header values are redacted from the response.
- **b2_unfinished_uploads** — Find abandoned multipart uploads that silently consume storage in a bucket. For 'bucket bloat', 'stuck/incomplete uploads', 'wasted storage'. Returns count, oldest upload age, and wasted bytes. Give the bucket by name or bucketId. Live listing, bounded by max_uploads and an internal time budget — on a very bloated bucket it returns a truncated result (and wasted_gb may be a lower bound) and recommends a lifecycle rule.
- **b2_update_bucket** — Update persistent settings on an existing B2 bucket: visibility, metadata, CORS, lifecycle, default encryption, replication, Object Lock, and default retention. Requires the writeBuckets capability. Use b2_list_buckets first to inspect the current bucketId/revision and use ifRevisionIs for safer retries; use s3_put_bucket_lifecycle only when you specifically need the S3 lifecycle API shape. Gated cases: bucketType allPublic, fileLockEnabled false, defaultRetention.mode null, lifecycleRules with daysFromHidingToDeleting, and any replicationConfiguration update.
- **b2_update_file_legal_hold** — Set or clear a legal hold on a specific file version in B2. When a legal hold is active, the file cannot be deleted regardless of retention settings. Requires the writeFileLegalHolds capability on the application key.
- **b2_update_file_retention** — Set or modify the retention policy on a specific file version in B2. Supports governance and compliance retention modes. In compliance mode, the retain-until date can only be extended. Requires the writeFileRetentions capability.
- **s3_abort_multipart_upload** — Abort an in-progress S3-compatible multipart upload and release all associated storage.
- **s3_complete_multipart_upload** — Finalize an S3-compatible multipart upload in B2 by assembling uploaded parts. Use only after s3_create_multipart_upload and s3_get_presigned_upload_part_url (or s3_upload_part_copy) have produced every required part; use s3_list_parts to verify uploaded parts before retrying. Requires writeFiles. Completion is idempotent only when B2 already committed the exact same part list; if the response is lost, reconcile with s3_head_object or s3_list_object_versions before retrying.
- **s3_copy_object** — Copy an object within B2 or between B2 buckets via B2's S3-compatible CopyObject API. The acl input is retained as a no-op S3 compatibility hint; B2 access follows the destination bucket policy.
- **s3_create_multipart_upload** — Initiate an S3-compatible multipart upload for a large object in B2 and return an UploadId. Requires the writeFiles capability. This starts an unfinished large-file upload that accrues storage for each uploaded part until you finalize with s3_complete_multipart_upload or discard it with s3_abort_multipart_upload; use s3_list_multipart_uploads to enumerate abandoned uploads, or b2_unfinished_uploads for storage-cost analysis of a selected bucket. Initiating the upload does not reserve or lock the destination key, so concurrent writes may still target it. Use s3_put_object only for tiny (≤1 MiB) inline payloads; prefer a single-object presigned PUT (s3_get_presigned_url) for most single-object transfers, including large ones; use multipart when an object is uploaded or copied as parallel parts. Flow: s3_create_multipart_upload → s3_get_presigned_upload_part_url → PUT each part directly to B2 (capture each ETag) → s3_complete_multipart_upload with those ETags. Parts are numbered 1–10000 and every part except the last must be ≥5 MiB, and no part may exceed 5 GiB.
- **s3_delete_object** — Delete one B2 object through the S3-compatible API. Use s3_list_object_versions first when you need to target a specific version or delete marker; use s3_delete_objects for batches up to 1000. Requires deleteFiles and destructive confirmation by policy; targeting a specific versionId additionally requires readFiles, because native B2 version binding is verified first. Omitting versionId applies normal S3 delete semantics and can create a delete marker in versioned buckets; providing versionId permanently removes that version after that binding check.
- **s3_delete_objects** — Delete multiple objects from a B2 bucket with bounded SDK concurrency (up to 1000 objects).
- **s3_get_bucket_location** — Get the region (location constraint) of a B2 bucket via the S3-compatible API. No native b2_* equivalent — used to verify region/endpoint pairing.
- **s3_get_object** — Read a SMALL object inline (≤1 MiB, returned base64) — for manifests, sidecars, and configs the agent must inspect — or stream any size to a local path with saveToPath. saveToPath writes the fetched bytes to the local filesystem (creating parent directories) via a temporary sibling file that replaces the target only after a complete download, so a failed transfer leaves any existing file untouched; it performs no mutation of B2 or any remote data. For real object data, generate a GetObject URL with s3_get_presigned_url and download directly from B2 (bytes never pass through the server or the model context).
- **s3_get_presigned_upload_part_url** — Generate short-lived presigned PUT URL bearer capabilities for parts of an S3-compatible multipart upload, so the client/worker uploads each part DIRECTLY to B2. Prefer this over s3_get_presigned_url for multipart uploads; use s3_get_presigned_url for single-object PUT/GET transfers. The response includes expiresIn/expiresAt; treat each URL as sensitive until it expires. Flow: s3_create_multipart_upload → s3_get_presigned_upload_part_url → PUT each part to its URL (capture the ETag from each response header) → s3_complete_multipart_upload with those ETags. Parts except the last must be ≥5 MiB, and no part may exceed 5 GiB.
- **s3_get_presigned_url** — Generate a short-lived presigned URL bearer capability for one B2 object — GetObject (download) or PutObject (upload). Prefer this for single-object transfers; use s3_create_multipart_upload and s3_get_presigned_upload_part_url for multipart uploads. The response includes the URL, operation, expiresIn, and expiresAt; treat the URL as sensitive until it expires. This is the preferred path for moving real object data: bytes flow directly between the client/worker and B2 and never pass through the MCP server. Note: presigned POST (browser form uploads) is NOT supported by B2; use a PutObject URL instead.
- **s3_head_bucket** — Check whether a B2 bucket exists and is reachable on the S3-compatible endpoint with the current credentials. Use this to validate S3-surface reachability (the native b2_list_buckets confirms existence but not S3 reachability).
- **s3_head_object** — Get metadata for a B2 object without downloading it. Returns content type, size, last modified, ETag, and custom metadata.
- **s3_list_multipart_uploads** — List in-progress S3-compatible multipart uploads for a B2 bucket. Use to resume or audit unfinished uploads before s3_get_presigned_upload_part_url, s3_complete_multipart_upload, or s3_abort_multipart_upload; use b2_unfinished_uploads when you need storage-cost analysis across bounded listings. Requires listFiles. Results are paginated with maxUploads (default 100, range 1-1000) and key/upload markers; delimiter responses include commonPrefixes.
- **s3_list_object_versions** — List object versions and delete markers in a B2 bucket using the S3-compatible API. Use before version-targeted s3_get_object, s3_head_object, s3_copy_object, or s3_delete_object calls; use s3_list_objects_v2 when current live objects are enough. Requires listFiles. Results are paginated with maxKeys (default 1000, max 1000) and paired key/version markers.
- **s3_list_objects_v2** — List objects in a B2 bucket via the S3-compatible ListObjectsV2 API. Supports prefix filtering, delimiter-based folder listings, and pagination.
- **s3_list_parts** — List the parts that have been uploaded for an in-progress S3-compatible multipart upload.
- **s3_put_bucket_lifecycle** — Set S3 lifecycle rules on a B2 bucket; pass rules: [] to clear the S3 lifecycle configuration. Supports AbortIncompleteMultipartUpload, Expiration, and NoncurrentVersionExpiration. B2 does not support Transition/storage-class rules.
- **s3_put_object** — Upload a SMALL object inline (≤1 MiB) to a B2 bucket — for manifests, sidecars, and tiny configs. Provide base64-encoded content or a local file path. For real object data, generate a PutObject URL with s3_get_presigned_url and upload directly to B2 (bytes never pass through the server), or use the multipart tools for large objects.
- **s3_upload_part_copy** — Copy a byte range from an existing B2 object into a part of an in-progress S3-compatible multipart upload, without downloading or re-uploading the data. Requires the writeFiles capability on the destination and read access to the source object. The source must be a bucket reachable within the same B2 account and region as the destination; cross-account sources cannot be copied this way. Use this to assemble large objects from data already in B2; use s3_get_presigned_upload_part_url instead when the client must upload new bytes. The copied part belongs to the upload created by s3_create_multipart_upload, so it obeys the 1–10000 part numbering, the ≥5 MiB minimum for every part except the last, and the 5 GiB per-part maximum. A missing or inaccessible source, or a range outside the source object, fails the part copy. Returns the part ETag to pass to s3_complete_multipart_upload.

## Claude Desktop Quick Installation
Install path detected from listing signals. Uses `npx` (confidence: high):

```json
"mcpServers": {
  "backblaze-b2-mcp-server": {
    "command": "npx",
    "args": ["-y","@backblaze-labs/b2-mcp"],
    "env": {
      "B2_APPLICATION_KEY_ID": "",
      "B2_APPLICATION_KEY": ""
    }
  }
}
```

**Requires environment variables:** `B2_APPLICATION_KEY_ID`, `B2_APPLICATION_KEY` — the values above are empty placeholders; fill in real credentials before running (see the repository for what each one is for).

## Documentation

## What Backblaze B2 MCP Server MCP server does

Backblaze B2 MCP Server connects MCP-compatible clients to Backblaze B2 Cloud Storage. It covers native B2 administration and S3-compatible object operations, so an agent can work with storage resources without requiring a separate custom integration.

The control-plane tools can authorize an account, inspect and manage buckets, list and revoke application keys, configure bucket notification rules, and change file legal-hold or retention settings. Partner and Groups operations are also available when the required Partner API credentials and account access are present.

The S3-compatible tools handle object metadata, listing, copying, deletion, version listing, and small inline transfers. Multipart tools support starting an upload, creating presigned part-upload URLs, listing parts, completing an upload, and aborting an upload.

## How it works

Backblaze B2 MCP Server uses the B2 SDK for native B2 operations and the AWS S3 SDK for S3-compatible storage operations. MCP clients call individual tools rather than receiving unrestricted access to the underlying credentials.

The server registers tools according to available capabilities. A normal application key can cover storage work and key management, while Partner or Groups functions need master-key credentials for an appropriately entitled account. Read-only keys can expose a smaller tool surface. Destructive operations, such as deleting buckets, keys, or objects, include safety gates.

Small object uploads and downloads through the inline S3 tools are limited to 1 MiB. Larger transfers should use the multipart workflow where applicable. The server also provides read-only MCP resources for non-secret server configuration, capabilities, and bucket information.

## Setup and configuration

Run the published npm package with a supported Node.js runtime and provide a Backblaze B2 application key. The required environment variables are `B2_APPLICATION_KEY_ID` and `B2_APPLICATION_KEY`. A non-master application key is sufficient for normal storage operations.

For Claude Desktop, configure an MCP server entry that runs `npx -y @backblaze-labs/b2-mcp`, then place the credentials in its environment block. The canonical executable is `b2-mcp`; `b2-mcp-server` is a transition alias. `B2_REGION` can provide an explicit fallback region, although S3 and report operations can derive the region after authorization.

Partner and Groups tools additionally require `B2_MASTER_KEY_ID` and `B2_MASTER_KEY`. Docker deployments use environment variables and default to HTTP transport; the published image should be pinned to a release version rather than relying on a mutable latest tag.

## Tools and capabilities

- Verify credentials and retrieve account information.
- Create, inspect, update, and delete buckets, subject to bucket and safety constraints.
- Read or replace public HTTPS bucket notification rules, with secrets redacted on reads.
- List, create, and irreversibly revoke application keys.
- Apply or clear object legal holds and retention settings.
- Manage Partner group membership when Partner API access is configured.
- List, copy, inspect, delete, and version objects through the S3-compatible interface.
- Perform multipart uploads with presigned part URLs.

## Limitations and notes

Inline S3 transfers are restricted to objects no larger than 1 MiB. Bucket deletion requires an empty bucket, and destructive actions may be blocked unless their safety conditions are satisfied. Notification targets must be public HTTPS endpoints.

The complete tool list is not necessarily visible to every client. Missing credentials, a read-only key, or absent master-key configuration can reduce the registered surface. Credential-free discovery may show advertised tools, but calls require valid B2 credentials.

_Full upstream README: https://allmcps.com/mcp/backblaze-b2-mcp-server/readme_