Skip to main content
Glama

Put It Online

by online.putit
OverviewDiscussionsAdmin

Get an upload URL for a large file

create_upload_session

For files too large to send inline: reserves a link and returns a one-time upload_url. PUT the raw bytes there (e.g. give the user the returned curl command), then poll get_link with the slug (and manage_token) until status is "live".

Input Schema

NameRequiredDescriptionDefault
slugNoCustom link name (3-40 letters, digits, dashes); available on plans with custom names.
filenameYesName of the file that will be uploaded, including extension.
passwordNoVisitors must enter this password to open the link; available on plans with password protection.
size_bytesNoExpected size, checked against your plan limit up front.

Output Schema

NameRequiredDescriptionDefault
curlYesReady-to-run command for the user.
linkYes
methodYes
headersYes
max_bytesYes
expires_atYes
upload_urlYesOne-time URL: PUT the raw file bytes here (no auth header needed).
complete_urlNoWhen present: POST here (no body) after the PUT finishes. The curl command already does it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / properties / link / properties / manage_token / description
      Previous value: -"Secret token for get_link/delete_link without an account. Only returned on creation."New value: +"Secret token returned on creation for every new link (keep it secret). Anonymous callers pass it to get_link/delete_link; a link in an account is managed by that account instead."
  2. Changed1 schema field changed
    • addedOutput schema / properties / link / properties / content_url
      Added value: +{
+  "description": "Only when live, for sites and single files: where the content itself is served (https://<slug>.putitcdn.com/…). Share `url` instead; it always works.",
+  "type": "string"
+}
  3. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Annotations only cover the coarse safety profile (readOnlyHint=false, idempotentHint=false, openWorldHint=true). The description adds the operationally critical traits: the URL is one-time, the bytes go via PUT at that URL, and completion must be confirmed by polling for status 'live'. This is exactly the extra context the annotations cannot supply.

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, front-loaded with the scoping condition, then the create→PUT→poll flow in order. No filler sentences; the parenthetical curl hint is genuinely actionable.

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?

With an output schema present, return-value explanation is unnecessary, and the description covers the full lifecycle an agent must drive: reserve, upload, poll. Nothing needed to invoke and follow through 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 description coverage is 100%, so slug, filename, password and size_bytes are already documented inline. The description only references slug and manage_token (the latter not even an input parameter) in the polling step, adding workflow context but no new parameter meaning. Baseline 3 applies.

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 (reserves a link, returns a one-time upload_url) and scopes it precisely to 'files too large to send inline', which implicitly separates it from the inline sibling upload_file. An agent can identify the job without opening the schema.

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?

Gives clear context for when to use it ('too large to send inline') and an explicit post-call workflow: PUT bytes, then poll get_link with slug/manage_token until status is 'live'. It stops short of naming upload_file as the small-file alternative, so the exclusion is implied rather than stated.

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

All Put It Online toolsInspect
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