Skip to main content
Glama

Get a link to send files from this machine

get_upload_link
Destructive

For files on the agent's own machine (a logo, fonts, pictures, a brand guide in the project folder): returns a one-time https address, good for 30 minutes, and the exact shell line to send files to it: curl -F file=@/path/to/logo.png . Run it from your own shell, once per file or with several -F file=@... in one command. Each file lands where add_logo, add_font, add_pictures or add_guide would put it (on the open setup; with no setup open, on the project's brand files: give project; a guide needs an open setup), is checked the same way, and curl's answer lists what arrived. kind: logo, font, picture, guide, or file (each file's own bytes decide: an image is a picture, a font file is a font, a PDF, Word or text file is a guide). What you give here (variant, family, role, caption, title, character, look, place...) applies to each file; -F caption=... beside a file overrides it for that command. Pictures of one of the business's own characters take character and look (-F character=Marsell -F look=3D), pictures of its own place take place, and each joins it (name them first with add_characters or add_places). Same size and type limits as the app's own uploads. Nothing big passes through your messages. kind voice clones the owner's own voice from recordings (the same as voice_clone, whose description says what consent means and how to record): give project, name and consent: true; every file in one curl command makes one voice, up to 25 recordings and 50 MB in all, of which Marsell hears at most 10 minutes. kind endcard sends the brand's end card video, the short card every one of its films ends on (an MP4, tall 9:16 and/or wide 16:9, one file per shape): give project; it replaces the end card Marsell made, and every later film ends on it. With series (a video series' id), it is that series' own end card instead: every later episode of the series ends on it, and other films keep the brand's.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "kind": "<kind>"
    },
    "name": "get_upload_link"
  }
}

Input Schema

NameRequiredDescriptionDefault
useNoFor pictures. post: a post the business already published, kept for its look.
kindYesWhat the files are: logo, font, picture, guide, file (each file's own bytes decide), voice (recordings of the owner's own voice to clone) or endcard (the end card video).
lookNoFor pictures, with character: which of its looks they show.
nameNoFor voice: the voice's name, what the owner picks it by in Create.
roleNoFor fonts.
labelNoFor logos: what this version is for.
placeNoFor pictures: the business's own place they show, by its name in add_places.
shapeNoFor endcard: the video's shape, only when it cannot be read from the video (tall is 9:16, wide is 16:9).
titleNoFor guides: its title (else the file's name).
familyNoFor fonts: the family's name (else read from the file name).
seriesNoFor endcard: a video series' id (series_read), to send that series' own end card instead of the brand's.
captionNoFor pictures: what it shows.
consentNoFor voice, required: true only when the owner said, in their own words, that it is their own voice or that they have the speaker's permission.
productNoFor pictures: the product it shows, by its name in add_products.
projectNoOnly with no setup open: the project (list_projects' id) whose brand files the files join. For voice, always: the project the voice is for (its id or exact name).
variantNoFor logos: Primary unless it is a light, dark or symbol version.
characterNoFor pictures: the business's own character they show, by its name in add_characters.
descriptionNoFor voice: what it sounds like, in a few words.
remove_noiseNoFor voice: true to take background noise out of the recordings first.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Adds substantial behavior beyond the annotations: the link is one-time and expires in 30 minutes, files are re-checked the same way as app uploads, size and type limits apply, curl's output lists what arrived, voice requires consent: true and caps at 25 recordings / 50 MB / 10 minutes heard, and endcard replaces the existing end card for all later films (consistent with destructiveHint=true). These are exactly the constraints an agent needs before calling, none of which are in the schema.

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?

It is front-loaded well: purpose, expiry, and the literal curl template come first, and every sentence carries operational content for one of the seven kinds. The weakness is form — a single dense paragraph heavy with parentheticals makes it harder to scan than a per-kind bulleted layout would be.

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 19-parameter, seven-mode tool with no output schema, it covers the risky and ambiguous paths (voice consent and limits, endcard replacement and series override, guide needing an open setup, project semantics) and indicates that curl's response lists what arrived. A few less-risky params (use, label, role, remove_noise, description) are delegated entirely to the schema, which is reasonable at 100% coverage.

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 coverage is 100%, so the baseline is 3, but the description adds real meaning the schema lacks: supplied params apply uniformly to each file, and '-F caption=... beside a file overrides it for that command', plus how character/look/place attach pictures to existing entities. It does not cover use, label, role, remove_noise, or description, leaving those to the 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?

States a specific verb and resource (returns a one-time https address plus the exact curl line) scoped precisely to files on the agent's own machine, and explicitly contrasts that with the add_logo/add_font/add_pictures/add_guide routes that receive the files. An agent can tell immediately which upload path to take.

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 trigger condition is clear and prominent: 'For files on the agent's own machine', and it explains why (nothing big passes through your messages). It maps outcomes onto sibling tools (add_logo, add_font, add_pictures, add_guide) but never says 'use this instead of those when the file is local', so the routing is inferable rather than spelled out.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.