Skip to main content
Glama

Upload a file

upload_file

Start adding an image or document from the person's computer to a board: PNG, JPEG, WebP, GIF, PDF, Word, PowerPoint, Excel, CSV, text or Markdown, up to 10 MB. Returns a URL to PUT the file to, with a ready curl command, and the file's upload name.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bytesYesThe file's exact size in bytes
fileNameYesThe file's name with its extension, like photo.jpg or report.pdf. The extension says what kind of file it is

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.7/5.0
Behavior4/5

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

Annotations only say readOnlyHint=false, destructiveHint=false, openWorldHint=false, so the description carries the interesting burden and delivers: it discloses the two-phase flow (a returned URL to PUT to), a ready curl command, and the upload name. That non-obvious 'you must complete the PUT yourself' behavior is exactly the kind of detail annotations cannot express.

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?

Two sentences, front-loaded with the action and scope, followed by the return contract. Little waste, though the long format enumeration is the least essential part of the first sentence.

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?

With no output schema, the description appropriately explains what comes back (URL to PUT to, curl command, upload name) alongside formats and the size limit. It is nearly complete for a 2-parameter tool; only the sibling relationship with add_file is left unaddressed.

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% for both parameters, so fileName and bytes are already documented with examples and the extension convention. The description's 'up to 10 MB' merely restates the schema maximum and adds no new per-parameter meaning, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb and resource ('Start adding an image or document ... to a board') plus the exact accepted formats and size cap, so the action is unambiguous. It falls short of a 5 because it never distinguishes itself from the closely named sibling add_file, leaving the agent to guess which one applies.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by 'from the person's computer to a board,' which suggests this is the entry point for local file content. However, there is no explicit when/when-not guidance and no mention of the competing add_file sibling, which shares nearly the same name and purpose.

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