Create a free sandbox object storage bucket; upload, download, list, inspect, and delete objects.
Scored across 8 tools
Every tool targets a distinct resource-action pair (bucket vs object vs permissions), and even similar operations like upload/download return clearly different URL types. No two tools overlap in a way that would cause an agent to misselect.
All tool names follow a consistent snake_case verb_noun pattern (create_bucket, delete_object, get_bucket_permissions, list_objects). Verb choices are descriptive and consistent across the set.
Eight tools is well-scoped for an object storage sandbox: bucket management, object lifecycle, metadata, and access checks are each represented. No redundant tools inflate the surface.
Core workflows—create bucket, upload, download, delete, list, and metadata—are covered, but bucket deletion is not exposed and explicit bucket listing is only indirectly available through permissions. This is a minor lifecycle gap rather than a blocking dead end.
Creates a 30-day bucket and its secret bearer token.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| bucket_name | Yes | Name of the newly created bucket. |
| bucket_token | Yes | Bearer credential required with the bucket name for all other operations. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate this is a non-read-only, non-idempotent, non-destructive operation. The description adds useful behavioral context beyond the annotations by specifying that the bucket is temporary (30 days) and that creating it also generates a secret bearer token, which clarifies side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It states the primary action first and then adds the two most important facts: the 30-day duration and the secret token, making every word meaningful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter creation tool with annotations and an output schema present, the description is complete. It explains what resource is created and the key side effect, and it does not need to describe return values because the output schema already covers them.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool accepts zero parameters, so there are no parameter semantics to clarify and the schema coverage is trivially 100%. The description provides sufficient high-level meaning for the operation without needing to document inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Creates'), names the resource ('bucket'), and adds the key distinguishing details: the 30-day lifetime and the issuance of a secret bearer token. This clearly separates it from sibling tools that operate on objects, metadata, or permissions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use guidance or exclusionary statements are provided. Usage is implied rather than stated: among the sibling tools, only create_bucket creates a bucket, so an agent can infer when to call it, but the description does not explicitly say so.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete an object; versioned buckets may retain older versions.
| Name | Required | Description | Default |
|---|---|---|---|
| object_key | Yes | Complete object key, including path-like prefixes. | |
| bucket_name | Yes | Bucket to operate on. | |
| bucket_token | Yes | Secret bearer token returned with the public bucket. |
| Name | Required | Description |
|---|---|---|
| deleted | Yes | True when the object was deleted. |
| object_key | Yes | Complete object key, including path-like prefixes. |
| version_id | No | |
| bucket_name | Yes | Bucket to operate on. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, and the description aligns with that. It adds useful context beyond the annotation by noting that versioned buckets may retain older versions, which helps the agent understand the scope of destruction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler. The main action is front-loaded, and the important versioning caveat is appended concisely.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation, the description is largely complete: the schema covers all required parameters, annotations cover destructiveness, and an output schema exists. The versioning caveat adds important edge-case context, though it could also mention permanent deletion for unversioned buckets or authorization requirements more explicitly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are fully documented by the input schema itself. The description does not add any meaning about how parameters relate to behavior, which meets the baseline but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: deleting an object. It is clear and unambiguous, though it does not explicitly differentiate from sibling tools like remove or upload operations, so it stops short of a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives, nor does it mention prerequisites, conditions, or exclusions. The only contextual note is about versioned buckets retaining versions, which is behavioral, not usage-oriented.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return a secret, short-lived GET URL for an object's bytes.
| Name | Required | Description | Default |
|---|---|---|---|
| object_key | Yes | Complete object key, including path-like prefixes. | |
| bucket_name | Yes | Bucket to operate on. | |
| bucket_token | Yes | Secret bearer token returned with the public bucket. |
| Name | Required | Description |
|---|---|---|
| url | Yes | Short-lived presigned HTTPS URL containing all authorization information. |
| http_method | Yes | HTTP method that must be used with the presigned URL. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and idempotentHint annotations, the description discloses that the URL is both 'secret' and 'short-lived', signaling the caller to treat it as sensitive and time-sensitive. It also clarifies that the tool returns a URL rather than the object bytes, which prevents a mistaken expectation of binary download. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no filler, front-loading the action and the two critical qualifiers ('secret', 'short-lived'). Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and three fully documented required parameters, the description covers the core behavior. The only gap is the absence of any usage alternative guidance, but that belongs to the usage dimension; operationally nothing needed to invoke the tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3; the description adds no parameter-level detail beyond what the schema already documents. The tool's three parameters are fully described in the schema, including examples for object_key and bucket_name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Return') and resource ('a secret, short-lived GET URL for an object's bytes'), clearly distinguishing it from metadata, upload, or delete operations. It doesn't name sibling tools explicitly, but the URL-returning behavior sets it apart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when a URL is needed rather than the bytes themselves, but it offers no explicit when-to-use guidance or exclusions relative to siblings like get_object_metadata or upload_object. There is no mention of alternatives, so the agent must infer context from the sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return bucket details with storage and egress usage.
| Name | Required | Description | Default |
|---|---|---|---|
| bucket_name | Yes | Bucket to operate on. | |
| bucket_token | Yes | Secret bearer token returned with the public bucket. |
| Name | Required | Description |
|---|---|---|
| egress | Yes | Monthly egress quota and current UTC-calendar-month usage in bytes. |
| storage | Yes | Storage quota and current usage in bytes. |
| created_at | Yes | UTC creation time |
| bucket_name | Yes | Bucket to operate on. |
| object_count | Yes | Number of objects |
| versioning_enabled | Yes | Whether object versioning is enabled. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description does not need to restate safety. It adds a small amount of behavioral context by naming the specific usage fields returned, but it does not go further into authentication or edge-case behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence communicates the operation and the key return fields without any filler. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only getter with an output schema, two fully documented parameters, and safety annotations, the description is complete. 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are fully documented in the schema itself. The description adds no extra detail about bucket_name or bucket_token beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Return') and identifies the resource ('bucket details'), then narrows the scope with 'storage and egress usage.' This clearly distinguishes it from sibling tools like get_bucket_permissions, which would handle permission details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use this tool to fetch bucket details plus storage and egress usage. It does not explicitly mention alternatives or exclusions, but the resource and return scope make the use case evident relative to the sibling tool list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return currently permitted buckets and operations.
| Name | Required | Description | Default |
|---|---|---|---|
| bucket_name | Yes | Bucket to operate on. | |
| bucket_token | Yes | Secret bearer token returned with the public bucket. |
| Name | Required | Description |
|---|---|---|
| buckets | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, fully covering the safe non-mutating profile. The description adds the semantic nuance that results reflect 'currently permitted' access, but no deeper behavioral traits are disclosed. There is 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler or repetition of the title or schema. Every word contributes to stating what the tool returns.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, has an output schema, fully documented parameters, and annotation-covered safety behavior. The only minor gap is that 'buckets' is plural while the required bucket_name implies this tool likely reports permissions for a single named bucket, which could be slightly clearer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both bucket_name and bucket_token already explained in the schema. The description does not add parameter syntax or role details beyond that, 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb, 'Return', and clearly identifies the resource: currently permitted buckets and operations. This distinguishes it from sibling tools like get_bucket (which likely returns bucket metadata) and the mutation-oriented tools such as create_bucket and delete_object.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied: this tool is for checking which buckets and operations are permitted. However, the description does not explicitly contrast it with alternatives like get_bucket, nor does it state when not to use it. The guidance is adequate but left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return an object's size, timestamps, ETag, content type, metadata, and tags.
| Name | Required | Description | Default |
|---|---|---|---|
| object_key | Yes | Complete object key, including path-like prefixes. | |
| bucket_name | Yes | Bucket to operate on. | |
| bucket_token | Yes | Secret bearer token returned with the public bucket. |
| Name | Required | Description |
|---|---|---|
| etag | No | Storage entity tag; it is not always a content checksum. |
| tags | No | |
| metadata | No | User-defined object metadata. |
| object_key | Yes | Complete object key, including path-like prefixes. |
| size_bytes | Yes | Object size in bytes. |
| version_id | No | |
| bucket_name | Yes | Bucket to operate on. |
| content_type | No | |
| last_modified | No | UTC time of the most recent modification. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the read-only, idempotent, non-destructive safety profile. The description adds value by specifying exactly which metadata attributes are returned, such as size, timestamps, ETag, content type, and tags. It does not address error behavior like missing objects, but this is largely mitigated by the output schema and annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-structured sentence with no filler. The main purpose is front-loaded and every phrase contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only metadata lookup, the description, schema, annotations, and output schema together provide sufficient context. Missing error-handling details are a minor gap, but the tool is otherwise well-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three parameters are already documented in the input schema. The description does not add parameter-level detail, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Return') and names the exact resource ('an object') plus the metadata fields returned. It clearly identifies what the tool does, though it does not explicitly differentiate itself from siblings like download_object or get_bucket.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied: call this when you need an object's metadata rather than its contents. No explicit guidance is given about when to prefer this over download_object, list_objects, or get_bucket, leaving selection partly to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List one page of objects and path-like prefixes, ordered by key.
| Name | Required | Description | Default |
|---|---|---|---|
| prefix | No | Only return keys beginning with this prefix. | |
| page_size | No | Maximum objects to return, from 1 to 1000. | |
| recursive | No | True for a flat listing; false for immediate children. | |
| page_token | No | Opaque continuation token from the preceding page. | |
| bucket_name | Yes | Bucket to operate on. | |
| bucket_token | Yes | Secret bearer token returned with the public bucket. |
| Name | Required | Description |
|---|---|---|
| objects | No | |
| bucket_name | Yes | Bucket to operate on. |
| common_prefixes | No | Immediate child prefixes when recursive is false. They behave like directories, although object storage has no real directories. |
| next_page_token | No | Opaque token for the next page. Pass it unchanged as page_token; null means there are no more results. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds valuable behavior: it returns 'one page' (pagination), 'path-like prefixes' (listing format), and 'ordered by key' (ordering guarantee)—details not covered by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, compact sentence that immediately states the action and key behaviors. No filler or redundant phrases; every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only listing operation with a rich output schema and fully documented parameters, the description is complete. It provides the essential nuances (one page, ordering, path-like prefixes) without needing to repeat schema details. A small addition like mentioning pagination continuation via page_token could be useful, but the schema already explains that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%; every parameter (prefix, page_size, recursive, page_token, bucket_name, bucket_token) already has a clear description in the input schema. The description does not add any extra parameter semantics beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific verb ('List') and resource ('objects and path-like prefixes'), plus the ordering ('ordered by key'). It clearly distinguishes from sibling write/delete tools because it is a read-only listing operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is given. However, the name and description clearly imply it is for listing objects, and the sibling tool names (upload_object, delete_object, etc.) make the intended use obvious. Still, there is no alternate tool comparison or exclusion statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return a secret, short-lived PUT URL for an object up to 5 GB.
| Name | Required | Description | Default |
|---|---|---|---|
| object_key | Yes | Complete object key, including path-like prefixes. | |
| bucket_name | Yes | Bucket to operate on. | |
| bucket_token | Yes | Secret bearer token returned with the public bucket. |
| Name | Required | Description |
|---|---|---|
| url | Yes | Short-lived presigned HTTPS URL containing all authorization information. |
| http_method | Yes | HTTP method that must be used with the presigned URL. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses important behavior not present in the annotations: the tool returns a URL rather than performing the upload itself, the URL is secret and short-lived, and there is a 5 GB limit. This adds meaningful context beyond the generic annotation hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler. It front-loads the core action ('Return a secret, short-lived PUT URL') and states the size limit efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple three-parameter tool with an output schema and clear annotations, the description provides enough context for correct invocation. It covers the essential behavioral details; only explicit sibling routing or failure scenarios are absent, and those are not critical here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with descriptions for bucket_name, object_key, and bucket_token, so the baseline is 3. The description adds the size limit but no parameter-specific syntax, which is acceptable given the schema's completeness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Return'), names the exact resource ('a secret, short-lived PUT URL'), and states the size cap ('up to 5 GB'). This clearly distinguishes the tool from siblings like download_object and clarifies that it does not upload content directly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied: the tool provides a PUT URL for uploading an object. However, it does not explicitly mention when to choose this tool over alternatives or any exclusions, leaving some routing decisions to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
create_bucket3 fields changedOutput schema / descriptionPrevious value: -"Credentials for a newly created public sandbox bucket."New value: +"Credentials for a newly created sandbox bucket."Output schema / properties / bucket_name / descriptionPrevious value: -"Name of the newly created public sandbox bucket."New value: +"Name of the newly created bucket."Output schema / properties / bucket_token / descriptionPrevious value: -"Bearer credential required with the bucket name for public bucket and object operations."New value: +"Bearer credential required with the bucket name for all other operations."delete_object2 fields changedInput schema / properties / object_key / examplesPrevious value: -[
- "reports/summary.json"
-]New value: +[
+ "data.parquet",
+ "reports/summary.json"
+]Output schema / properties / object_key / examplesPrevious value: -[
- "reports/summary.json"
-]New value: +[
+ "data.parquet",
+ "reports/summary.json"
+]download_object1 field changedInput schema / properties / object_key / examplesPrevious value: -[
- "reports/summary.json"
-]New value: +[
+ "data.parquet",
+ "reports/summary.json"
+]get_bucket15 fields changedOutput schema / properties / created_at / anyOfRemoved value: -[
- {
- "format": "date-time",
- "type": "string"
- },
- {
- "type": "null"
- }
-]Output schema / properties / created_at / defaultRemoved value: -nullOutput schema / properties / created_at / descriptionPrevious value: -"UTC creation time, when available."New value: +"UTC creation time"Output schema / properties / created_at / formatAdded value: +"date-time"Output schema / properties / created_at / typeAdded value: +"string"Output schema / properties / object_count / anyOfRemoved value: -[
- {
- "minimum": 0,
- "type": "integer"
- },
- {
- "type": "null"
- }
-]Output schema / properties / object_count / defaultRemoved value: -nullOutput schema / properties / object_count / descriptionPrevious value: -"Number of objects, when requested and available."New value: +"Number of objects"Output schema / properties / object_count / minimumAdded value: +0Output schema / properties / object_count / typeAdded value: +"integer"Output schema / properties / versioning_enabled / anyOfRemoved value: -[
- {
- "type": "boolean"
- },
- {
- "type": "null"
- }
-]Output schema / properties / versioning_enabled / defaultRemoved value: -nullOutput schema / properties / versioning_enabled / descriptionPrevious value: -"Whether object versioning is enabled, when available."New value: +"Whether object versioning is enabled."Output schema / properties / versioning_enabled / typeAdded value: +"boolean"Output schema / requiredPrevious value: -[
- "bucket_name",
- "storage",
- "egress"
-]New value: +[
+ "bucket_name",
+ "created_at",
+ "object_count",
+ "versioning_enabled",
+ "storage",
+ "egress"
+]get_object_metadata2 fields changedInput schema / properties / object_key / examplesPrevious value: -[
- "reports/summary.json"
-]New value: +[
+ "data.parquet",
+ "reports/summary.json"
+]Output schema / properties / object_key / examplesPrevious value: -[
- "reports/summary.json"
-]New value: +[
+ "data.parquet",
+ "reports/summary.json"
+]list_objects1 field changedOutput schema / properties / objects / items / properties / object_key / examplesPrevious value: -[
- "reports/summary.json"
-]New value: +[
+ "data.parquet",
+ "reports/summary.json"
+]upload_object1 field changedInput schema / properties / object_key / examplesPrevious value: -[
- "reports/summary.json"
-]New value: +[
+ "data.parquet",
+ "reports/summary.json"
+]create_bucketdelete_objectdownload_objectget_bucketget_bucket_permissionsget_object_metadatalist_objectsupload_objectPersistent file storage for AI agents via MCP and curl. Upload, download, and version files.
Get share links, publish and manage websites, artifacts and agents. No account needed.
Hosted Python sandbox for package runtime verification: pip install and usable-import evidence.
Deploy and manage web apps on InstaPods: create pods, push files, run commands, read logs.
Add one secure layer between your agents and this server.
