quickS3

by com.quicks3

Overview Discussions Admin

Server Details

Browse, upload, download, and share files in your S3-compatible buckets with delegated roles.

Ownership verified

Status: Healthy
Uptime: 99.7% over 21 days
OAuth: Works in Glama
Last Tested: 2026-10-06 22:56
Transport: Streamable HTTP · MCP 2025-11-25
URL

TDQS

A4.4/5.0

Scored 2026-09-24 04:20 across 6 tools

Disambiguation4/5

The link-creating tools are clearly differentiated: download links are short-lived and single-use for the user, while share links are public and intended for sharing. The listing tools overlap slightly (list_buckets vs list_connections), but the descriptions explain when to use which.

Naming Consistency5/5

All tools follow a consistent snake_case verb_noun pattern: create_* for URL/link creation and list_* for listing operations. The one minor variance is create_upload_url using 'url' instead of 'link', but this is a small lexical difference, not a convention break.

Tool Count5/5

Six tools is a well-scoped set for this server's purpose: three create operations for downloads, shares, and uploads, plus three listing operations for connections, buckets, and objects. There are no redundant or filler tools.

Completeness4/5

The core operations—creating download links, share links, upload URLs, and listing storage resources—are well covered. The main gap is the lack of an explicit way to revoke or manage created links, relying instead on expiry and external access-grant changes.

Available Tools

6 tools

create_download_linkCreate download linkA

Read-onlyIdempotent

Inspect

Create a short-lived download link (valid 5 minutes, single use) for one object. Download the file by following the link, e.g. with curl -L -o output.bin "<uri>". quickS3 never sees or stores the file contents; the link redirects directly to your storage provider.

ParametersJSON Schema

Name	Required	Description
`key`	Yes	Object key, e.g. "reports/2026/q3.csv"
`bucket`	Yes	Bucket name
`connectionId`	Yes	Connection ID from list_connections

Output Schema

ParametersJSON Schema

Name	Required	Description
`url`	Yes
`expiresAt`	Yes
`transferId`	Yes

TDQS

A4.5/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond annotations, the description discloses valuable behavioral details: the link is valid for 5 minutes, single use, redirects directly to the storage provider, and quickS3 never sees or stores file contents. This meaningfully enriches the readOnly and non-destructive hints already present.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and well-structured: it states the core behavior first, then usage via curl, then a useful privacy guarantee. Every sentence contributes meaningful information without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple 3-parameter schema, 100% schema coverage, an output schema, and annotations covering safety, the description provides all necessary operational context. An agent has enough information to call the tool correctly and understand the resulting link's behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents connectionId, bucket, and key with examples. The description adds general context about the generated link but does not add further parameter-level detail, matching the baseline for high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific verb and resource: 'Create a short-lived download link ... for one object.' It also distinguishes itself from siblings like create_upload_url and create_share_link by emphasizing download, short validity, and single-use behavior.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context on when this tool is appropriate: for downloading one specific object via a short-lived, single-use link. It does not explicitly name alternatives or exclusions, but the download vs upload/link-sharing distinction is clear enough for an agent to route correctly.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

create_share_linkCreate share linkAInspect

Create a public share link for one object. Anyone who has the link can download the file without a quickS3 account, until it expires. Use this only when the user asks to share a file with someone; to download a file yourself, use create_download_link. Needs Read and Share on the file. The link never outlives this access grant: revoking the grant, losing Read or Share on the file, or the organisation switching share links off disables it.

ParametersJSON Schema

Name	Required	Description
`key`	Yes	Object key, e.g. "reports/2026/q3.csv"
`bucket`	Yes	Bucket name
`connectionId`	Yes	Connection ID from list_connections
`expiresInSeconds`	No	How long the link stays valid, in seconds: from 300 (5 minutes) to 2592000 (30 days). Default 86400 (24 hours).

Output Schema

ParametersJSON Schema

Name	Required	Description
`shareUrl`	Yes
`expiresAt`	Yes
`shareLinkId`	Yes
`limitedByGrant`	Yes

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description goes well beyond the annotations by disclosing that the link is public, works without an account, expires, and can be disabled if the access grant is revoked, permissions are lost, or the organization disables share links. This is valuable behavioral context about an externally visible, non-idempotent side effect.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four sentences deliver purpose, usage guidance, alternative routing, permission requirements, and edge-case behavior with no filler. The most important differentiating facts are front-loaded before the alternative tool is mentioned.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with this complexity, the description covers what the tool does, when to use it, when not to use it, required permissions, and link lifecycle behavior. The existence of an output schema means return-value documentation is not required in the description, so nothing essential is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema fully documents all four parameters including the valid range and default for expiresInSeconds. The description does not add parameter-level meaning, which is acceptable here because the schema already carries that burden.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a concrete verb and resource: 'Create a public share link for one object.' It also immediately distinguishes itself from create_download_link, making the tool's purpose unmistakable among siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly says 'Use this only when the user asks to share a file with someone' and names the alternative 'to download a file yourself, use create_download_link.' It even states required permissions, leaving no ambiguity about when this tool should be selected.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

create_upload_urlCreate upload URLA

Idempotent

Inspect

Create a short-lived presigned upload URL (valid 15 minutes) for one object. Upload the file directly to your storage provider with an HTTP PUT to the returned url, sending every header in the returned headers (e.g. curl -H "x-ms-blob-type: BlockBlob" -T localfile "<url>" for Azure). Uploads fail without those headers. quickS3 never sees or stores the file contents.

ParametersJSON Schema

Name	Required	Description
`key`	Yes	Object key to write, e.g. "reports/2026/q3.csv"
`size`	Yes	File size in bytes
`bucket`	Yes	Bucket name
`overwrite`	No	Allow replacing an existing object (default false)
`contentType`	No	Content type of the file, e.g. "text/csv"
`connectionId`	Yes	Connection ID from list_connections

Output Schema

ParametersJSON Schema

Name	Required	Description
`url`	Yes
`method`	Yes
`headers`	Yes
`maxBytes`	Yes
`expiresAt`	Yes

TDQS

A4.5/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses important behavioral details beyond the annotations: the URL is valid for 15 minutes, uploads fail without the returned headers, and quickS3 never sees or stores file contents. This meaningfully informs the agent about side effects and constraints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three focused sentences front-load the core purposehare, then add critical usage details and a concrete curl example. No filler or redundant restatement of the schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description, combined with the complete schema and the existence of an output schema, covers all essential aspects: URL lifetime, required headers, direct upload behavior, and the storage provider flow. An agent has enough information to invoke and complete the upload correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already covers all 6 parameters with descriptions, so the description does not need to elaborate. The description adds context about the returned url/headers rather than the input parameters, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: creates a short-lived presigned upload URL scoped to one object. This clearly distinguishes it from sibling tools like create_download_link or create_share_link, which serve different purposes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides clear workflow context by explaining that the file should be uploaded via HTTP PUT to the returned URL, with all returned headers. It implicitly guides when to use this tool, though it does not explicitly name alternatives or state when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_bucketsList bucketsA

Read-onlyIdempotent

Inspect

List the buckets of one storage connection that this access grant can see. list_connections already includes buckets; use this to refresh a single connection.

ParametersJSON Schema

Name	Required	Description	Default
`connectionId`	Yes	Connection ID from list_connections

Output Schema

ParametersJSON Schema

Name	Required	Description
`stale`	Yes
`buckets`	Yes
`refreshedAt`	Yes

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful context about access-grant scoping and single-connection refresh behavior, enhancing transparency beyond the annotations without contradicting them.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no filler: the first states the action and scope, the second provides the sibling-tool distinction and usage condition. Every word earns its place and the key information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a low-complexity, one-parameter read-only tool with a full output schema and comprehensive annotations, the description covers the essential scoping and usage context. Nothing an agent needs to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema description coverage, the schema already explains connectionId as 'Connection ID from list_connections.' The description reinforces that it is a single storage connection but adds little new semantic meaning beyond the schema, so the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'List the buckets of one storage connection that this access grant can see.' It explicitly distinguishes itself from list_connections by noting that list_connections already includes buckets, so an agent can immediately tell the two apart.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear usage direction: use this to refresh a single connection, and notes that list_connections already includes buckets. This names the alternative and the condition for selecting this tool, leaving no ambiguity about when to call it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_connectionsList storage connectionsA

Read-onlyIdempotent

Inspect

List the storage connections (S3, R2, Spaces, B2, ...) this access grant can see, with the cached bucket inventory of each. A connection whose buckets could not be listed has bucketsError instead of buckets.

ParametersJSON Schema

Name	Required	Description	Default
`includeBuckets`	No	Also list the cached buckets of each connection (default true). Set false to omit bucket inventories.

Output Schema

ParametersJSON Schema

Name	Required	Description
`connections`	Yes

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare read-only, idempotent, non-destructive behavior. The description adds valuable behavioral detail beyond annotations: results include cached bucket inventories, and a connection with failed bucket listing exposes bucketsError instead of buckets. This helps an agent anticipate error-shaped returns.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no filler. The core action and scope are front-loaded in the first sentence, and the second sentence adds a necessary edge-case behavior (bucketsError). Every clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with one optional, fully documented parameter, rich annotations, and an output schema, the description is complete. It covers scope, return contents, and an error variant, so an agent has everything needed to invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the includeBuckets parameter is fully documented in the schema (default true, false omits bucket inventories). The tool description reinforces the bucket-inventory concept but does not add meaning beyond what the schema already provides, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('List') and resource ('storage connections') with explicit scoping ('this access grant can see'). The examples (S3, R2, Spaces, B2) and mention of cached bucket inventory make it clearly distinct from sibling tools like list_buckets and list_objects.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context: this tool enumerates connections visible to an access grant and includes their bucket inventories. It does not explicitly state when to choose this over list_buckets or list_objects, but the resource-level distinction is clear enough that an agent can infer the appropriate use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_objectsList objectsA

Read-onlyIdempotent

Inspect

List objects and folders in a bucket, filtered to prefixes this access grant may read. Folders end with "/" and appear as kind "prefix".

ParametersJSON Schema

Name	Required	Description
`limit`	No	Maximum objects per page (default 100)
`bucket`	Yes	Bucket name
`prefix`	No	Folder prefix to list, e.g. "reports/2026/". Omit for the bucket root.
`connectionId`	Yes	Connection ID from list_connections
`continuationToken`	No	Opaque token from a previous page

Output Schema

ParametersJSON Schema

Name	Required	Description
`objects`	Yes
`continuationToken`	No

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint false, covering the safety profile. The description adds meaningful behavioral context beyond annotations: the access-grant filtering and the representation of folders as kind 'prefix' with trailing slash. These details help the agent interpret results correctly. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences with no wasted words. The primary purpose is front-loaded, and the folder representation detail is placed second. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity, rich annotations, and the presence of an output schema (which covers return value details), the description is complete. It addresses access scoping and folder representation, while pagination is handled by the continuationToken parameter in the schema. Nothing critical is missing for an agent to call this tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so each parameter is documented. The description adds value by clarifying that 'prefix' is used to list subfolders (with an example 'reports/2026/') and that folders are returned as kind 'prefix'. This helps an agent understand the semantic relationship between prefix and folder listing beyond the bare schema definitions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'list' and the resource 'objects and folders in a bucket', and adds specificity about folder representation (kind 'prefix'). It is immediately distinguishable from sibling tools like list_buckets and list_connections by the explicit 'in a bucket' scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not explicitly mention when to use this tool versus alternatives, nor does it state any exclusions. It does include a usage constraint ('filtered to prefixes this access grant may read') which clarifies access scope, but that is about permissions, not tool selection. The purpose is clear enough that an agent might infer the appropriate tool, but explicit guidance is missing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

2 tool updatesSep 21, 2026

Changedlist_buckets3 fields changed

addedOutput schema / properties / refreshedAt
```
Added value: +{
+  "type": "string"
+}
```
addedOutput schema / properties / stale
```
Added value: +{
+  "type": "boolean"
+}
```

changedOutput schema / required

Previous value: -[
-  "buckets"
-]New value: +[
+  "buckets",
+  "refreshedAt",
+  "stale"
+]

Changedlist_connections3 fields changed

changedInput schema / properties / includeBuckets / description

Previous value: -"Also list the buckets of each connection (default true). Set false for a faster answer without contacting the storage providers."New value: +"Also list the cached buckets of each connection (default true). Set false to omit bucket inventories."

addedOutput schema / properties / connections / items / properties / bucketsRefreshedAt
```
Added value: +{
+  "type": "string"
+}
```
addedOutput schema / properties / connections / items / properties / bucketsStale
```
Added value: +{
+  "type": "boolean"
+}
```

2 tool updatesSep 17, 2026

Changedcreate_download_link2 fields changed

addedOutput schema / properties / url
```
Added value: +{
+  "type": "string"
+}
```

changedOutput schema / required

Previous value: -[
-  "transferId",
-  "expiresAt"
-]New value: +[
+  "url",
+  "transferId",
+  "expiresAt"
+]

Changedlist_connections3 fields changed

addedInput schema / properties / includeBuckets

Added value: +{
+  "description": "Also list the buckets of each connection (default true). Set false for a faster answer without contacting the storage providers.",
+  "type": "boolean"
+}

addedOutput schema / properties / connections / items / properties / buckets

Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

addedOutput schema / properties / connections / items / properties / bucketsError
```
Added value: +{
+  "type": "string"
+}
```

6 tool updatesSep 16, 2026

Changedcreate_download_link1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "additionalProperties": false,
+  "properties": {
+    "expiresAt": {
+      "type": "string"
+    },
+    "transferId": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "transferId",
+    "expiresAt"
+  ],
+  "type": "object"
+}

Changedcreate_share_link1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "additionalProperties": false,
+  "properties": {
+    "expiresAt": {
+      "type": "string"
+    },
+    "limitedByGrant": {
+      "type": "boolean"
+    },
+    "shareLinkId": {
+      "type": "string"
+    },
+    "shareUrl": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "shareUrl",
+    "shareLinkId",
+    "expiresAt",
+    "limitedByGrant"
+  ],
+  "type": "object"
+}

Changedcreate_upload_url1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "additionalProperties": false,
+  "properties": {
+    "expiresAt": {
+      "type": "string"
+    },
+    "headers": {
+      "additionalProperties": {
+        "type": "string"
+      },
+      "propertyNames": {
+        "type": "string"
+      },
+      "type": "object"
+    },
+    "maxBytes": {
+      "type": "number"
+    },
+    "method": {
+      "type": "string"
+    },
+    "url": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "url",
+    "method",
+    "headers",
+    "expiresAt",
+    "maxBytes"
+  ],
+  "type": "object"
+}

Changedlist_buckets1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "additionalProperties": false,
+  "properties": {
+    "buckets": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "buckets"
+  ],
+  "type": "object"
+}

Changedlist_connections1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "additionalProperties": false,
+  "properties": {
+    "connections": {
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "canRead": {
+            "type": "boolean"
+          },
+          "canWrite": {
+            "type": "boolean"
+          },
+          "id": {
+            "type": "string"
+          },
+          "name": {
+            "type": "string"
+          },
+          "provider": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "id",
+          "name",
+          "provider",
+          "canRead",
+          "canWrite"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "connections"
+  ],
+  "type": "object"
+}

Changedlist_objects1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "additionalProperties": false,
+  "properties": {
+    "continuationToken": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "objects": {
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "key": {
+            "type": "string"
+          },
+          "kind": {
+            "enum": [
+              "object",
+              "prefix"
+            ],
+            "type": "string"
+          },
+          "lastModified": {
+            "type": "string"
+          },
+          "size": {
+            "type": "number"
+          }
+        },
+        "required": [
+          "key",
+          "kind",
+          "size"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "objects"
+  ],
+  "type": "object"
+}

6 tool updatesSep 16, 2026
- First observedcreate_download_link
- First observedcreate_share_link
- First observedcreate_upload_url
- First observedlist_buckets
- First observedlist_connections
- First observedlist_objects

Publisher details

Operator: Gone Coding Ltd · Publisher source
Operator website: https://quickS3.com
Vendor relationship: First-party · Publisher source
Documentation: https://quicks3.com/s3-mcp-server/
Trust center: https://quicks3.com/docs/security/model/
Restrictions: $19/month Includes 10 users, then $2/user/month · Publisher source

Related MCP Connectors

Revdoku A
com.revdoku
Cloud storage with email-receiving buckets. Store and share files with people and AI agents.
Content Management Systems Cloud Storage
392
IronShard Object Storage Sandbox A
ai.ironshard
Create a free sandbox object storage bucket; upload, download, list, inspect, and delete objects.
Cloud Storage Developer Tools
81
X02 File HostingOAuth
me.x02
Upload, find, organize and share files on your X02 account with scoped, revocable access.
Cloud Storage Security
12
ctaylor86-mcp-video-download-serverOAuth
ai.smithery
Connect your video workflows to cloud storage. Organize and access video assets across projects wi…
Multimedia Processing Cloud Storage App Automation
2

Related MCP Servers

AWS S3 MCP Server
Cloud Storage Cloud Platforms File Systems
OpenWorkspace-o1
F
license
Not graded
quality
D
maintenance
Provides secure access to AWS S3 buckets through pre-signed URLs, enabling listing, downloading, uploading, and deleting objects.
Updated 2 years ago (2025-03-16 03:07 UTC)
2
-
S3 MCP Server
Cloud Storage Cloud Platforms File Systems
AM1010101
A
license
A
quality
D
maintenance
Enables interaction with S3-compatible storage services like AWS S3 and Cloudflare R2, supporting bucket management, object listing, reading, uploading, and deletion operations.
Updated 10 months ago (2025-12-19 01:34 UTC)
5
121 npm
ISC
s3-mcp
Cloud Storage Cloud Platforms
tompetk
A
license
A
quality
C
maintenance
Enables AI assistants to explore and manage S3-compatible object storage (AWS S3, RustFS, MinIO, Cloudflare R2) by listing buckets and objects, inspecting metadata, and reading object contents with capped range requests. Write operations such as upload and delete are available but disabled unless explicitly enabled, with optional bucket allow-listing and custom TLS trust.
Updated 24 days ago (2026-09-13 10:33 UTC)
6
MIT
AWS S3 MCP Server
Cloud Platforms Cloud Storage
gangadharrr
A
license
Not graded
quality
D
maintenance
Enables interaction with AWS S3 storage through bucket operations (create, delete, list), object management (upload, download, delete, list), and bucket policy configuration using AWS credentials.
Updated 8 months ago (2026-02-21 12:00 UTC)
13 npm
2
MIT

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?