Skip to main content
Glama

Get a link to upload a photo or a Word file

get_upload_link

A one-time page where the user uploads a file for the tools that need one: a photo (JPEG, PNG or WebP) for the image tools and scan_document, or a Word file (.docx or .doc) for word_to_pdf, up to 25 MB. It gives the file_id to pass to them. You cannot hand over a file from this chat yourself: give the user the link, ask them to open it and choose the file, and continue when they say it is done. In a client that can run shell commands (Claude Code), upload a local file yourself with the upload_command. The link works for 1 hour; the file is kept for 24 hours. Free.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

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

Input Schema

NameRequiredDescriptionDefault

No arguments

Output Schema

NameRequiredDescriptionDefault
file_idYes
expires_atYes
upload_urlYes
upload_commandYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare the generic profile (readOnlyHint=false, destructiveHint=false, openWorldHint=false, idempotentHint=false), while the description adds the operationally critical facts: the page is one-time, the link expires in 1 hour, the file is retained 24 hours, the size cap is 25 MB, the call is free, and the agent cannot perform the upload itself. These are exactly the behaviors a caller would otherwise get wrong.

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, consumers, formats and size limit are front-loaded in the first sentence, followed by the interaction protocol and then the lifetime/cost facts. Dense but every clause carries information; the long compound sentences are the only mild cost to readability.

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?

For a zero-parameter tool with an output schema, the description supplies everything an agent needs: what triggers its use, the human-in-the-loop protocol, the shell-client alternative, and the expiry/retention constraints. No material gap remains.

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?

The tool takes zero parameters, so the baseline is 4 and there is no parameter semantics to clarify. The description usefully frames the output ('It gives the file_id to pass to them'), even though a full output schema already exists.

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 ('a one-time page where the user uploads a file') and enumerates exactly which sibling tools consume it (image tools, scan_document, word_to_pdf) with accepted formats. An agent can distinguish it from every sibling without opening a 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?

Gives explicit when-to-use (tools that need a file), an explicit constraint ('you cannot hand over a file from this chat yourself'), the step-by-step flow (give link, ask user to open and choose, continue when they confirm), and an explicit alternative path (upload_command in shell-capable clients). Nothing is left to inference.

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.

Resources