Skip to main content
Glama
aspose-cells-cloud

Aspose.Cells Cloud MCP Server

Official
by aspose-cells-cloud
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Upload File

upload_file

Upload Base64-encoded file content to Aspose Cloud Storage and get a unique file_uuid. Use the returned UUID in later calls to reference the file for Excel processing.

Instructions

Upload file content (provided as a Base64 string) to Aspose Cloud Storage and return a file_uuid. The file is stored in its own uuid folder: when file_name is given the file keeps that name (folder = uuid, name = file_name, e.g. /report.xlsx); when file_name is empty a default name is used. Later calls address the file via the returned file_uuid regardless of the name.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
file_nameNo
file_content_b64stringYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv26.4.1
    • addedInput schema / properties / file_name
      Added value: +{
+  "default": null,
+  "type": "string"
+}
  2. First observedv26.4.0

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description carries the behavioral transparency burden. It discloses that the file is stored in a UUID folder, the naming behavior when file_name is provided or empty, and that future calls reference the file by UUID regardless of name. It does not cover error conditions, size limits, or persistence guarantees, but the core side effects and addressing model are transparent.

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: the first sentence states the action and return value, and the second sentence explains the naming conventions. Every sentence adds meaningful information with no redundancy or filler.

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

Completeness4/5

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

For a tool with no output schema and no annotations, the description covers the main operational facts: input format, storage behavior, file naming, and UUID-based addressing for later calls. It could add the actual default name and response structure details, but it is sufficiently complete for an agent to select and invoke the 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 0%, so the description must explain the parameters. It explains that file_content_b64string is a Base64 string and that file_name controls the stored file name within the UUID folder, including the empty-name default behavior. It does not specify the default name format or allowed file types, but it adds substantial meaning beyond the bare schema.

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 and resource: uploading Base64 file content to Aspose Cloud Storage and returning a file_uuid. It also explains the naming/storage behavior, which distinguishes this tool from the many conversion/cleanup siblings. The purpose is unambiguous.

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 for when to use the tool: when you have Base64 file content that needs to be stored for later use via file_uuid. It does not explicitly enumerate alternatives or exclusions, but its role is distinct from siblings like download_file and the conversion tools, so the usage context is sufficiently clear.

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

Deploy Server

Other Tools