Skip to main content
Glama
Sign In
Unilytics MCP Server

Unilytics MCP Server

Official
by TeamUnilytics
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

upload_file_to_project

Initiates storing an original project file byte-for-byte by returning an upload URL and form details; POST the file to that URL, then register its s3_key to record it in the project.

Instructions

Step 1 of storing an original file (template deck, sheet, doc, image) in a project, kept byte for byte so it can be downloaded and edited later. For searchable text, the KB tools fit instead.

Returns {uploadUrl, uploadDetails, s3_key, upload_requires}. The upload completes with a
multipart/form-data POST of the file to `uploadUrl`: every property of `uploadDetails` as a form
field, then the file itself under the field `file` as the LAST field (S3 ignores fields after
`file`); a 201 response means success. register_project_file(s3_key) then records the file.

Example (curl):
  curl -X POST "<uploadUrl>" \
    -F key="<uploadDetails.key>" -F Policy="<uploadDetails.Policy>" \
    -F X-Amz-Algorithm="..." -F X-Amz-Credential="..." -F X-Amz-Date="..." \
    -F X-Amz-Signature="..." -F Content-Type="<uploadDetails.Content-Type>" \
    -F success_action_status="201" \
    -F file=@/path/to/your/file.pptx
  (every field present in uploadDetails, with -F file=@... last.)

Allowed: pptx/ppt/xlsx/xls/docx/doc/pdf/csv/md/txt/json/png/jpg/gif/svg/webp (max 256MB).

The POST needs outbound HTTPS access to Amazon S3. In an environment without it, the POST fails
before reaching S3 (e.g. "CONNECT tunnel failed", "Could not resolve host", HTTP 000 or a proxy
403), and a retry fails the same way; create_upload_link gives the user a browser page for the
same upload, or the file can be uploaded in the Unilytics app.

Input Schema

NameRequiredDescriptionDefault
filenameYes
byte_sizeNo
project_idYes
content_typeNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.1.0

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only declare the CRUD safety profile; the description adds the substantial behavior an agent actually needs: the exact return shape ({uploadUrl, uploadDetails, s3_key, upload_requires}), that the upload completes via a multipart POST with all uploadDetails fields before a final `file` field, that 201 means success, that register_project_file(s3_key) is required to record it, and the outbound-S3 failure signatures with a retry is futile warning. The openWorldHint=false annotation is in mild tension with the stated need for outbound HTTPS to Amazon S3, but it is a bounded, known endpoint rather than genuinely open-ended interaction, so this reads as under-labeling rather than a direct contradiction.

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

Conciseness4/5

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

Purpose and the return contract are front-loaded, and the curl example earns its space because the field-ordering rule is hard to get right from prose alone. The S3-failure paragraph is somewhat long, but it carries actionable retry guidance rather than filler.

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?

Despite no output schema, the description fully documents the return object and the required follow-up call, so an agent knows how to finish the two-step upload. Constraints (type allowlist, 256MB), transport requirements, and failure modes are all present, leaving little the caller must guess.

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 0% (only bare titles plus defaults byte_size=0 and content_type=null), and the description never explains these four arguments individually. It partially compensates by listing allowed extensions (relevant to filename/content_type) and the 256MB cap (relevant to byte_size), but leaves the meaning of the defaults, whether byte_size triggers validation, and content_type inference unaddressed.

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?

Opens with a specific verb+resource+role: 'Step 1 of storing an original file (template deck, sheet, doc, image) in a project', and contrasts the scope with the KB tools for searchable text and with register_project_file as the follow-up step. An agent can place this tool in a multi-step pipeline without opening any schema.

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?

Explicitly states when this tool fits (preserving the original bytes for later download/edit) versus when it does not (searchable text -> KB tools), and names the alternative create_upload_link for environments without outbound HTTPS to S3. This covers when-to-use, when-not, and a fallback path.

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