Skip to main content
Glama
Sign In

Flaghand

by com.flaghand
OverviewDiscussionsAdmin

Upload a photo, video, PDF document or SRT captions file (the raw bytes as the body)

uploadMedia
Destructive

Upload a photo, video, PDF document or SRT captions file (the raw bytes as the body). HTTP 402 media_storage_full includes used_bytes, limit_bytes and next_step when card-free workspace storage is full; workspace_inactive indicates a lapsed plan.

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": "uploadMedia"
  }
}

Input Schema

NameRequiredDescriptionDefault
altNo
widthNoThe image's width in pixels, for the previews: digits only, without px, at least 1. Used only when the file's own width can't be read (an animated WebP, an unusual video); the file's own size always wins. Leave it out if you don't know it.
heightNoThe image's height in pixels, for the previews: digits only, without px, at least 1. Used only when the file's own height can't be read; the file's own size always wins. Leave it out if you don't know it.
durationNoA video's length in seconds, without a unit suffix, more than 0. Used only when the file's own duration can't be read.
filenameNo
workspaceNoLeave out for the token's workspace (ws_…).
data_base64NoThe file's bytes, base64-encoded.
content_typeNoThe file's type.
idempotency_keyNoA new UUID per request; resending the same key and request is a safe retry.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / content_type / enum
      Previous value: -[
-  "image/jpeg",
-  "image/png",
-  "image/webp",
-  "image/gif",
-  "video/mp4",
-  "video/quicktime",
-  "application/pdf"
-]New value: +[
+  "image/jpeg",
+  "image/png",
+  "image/webp",
+  "image/gif",
+  "video/mp4",
+  "video/quicktime",
+  "application/pdf",
+  "application/x-subrip"
+]
  2. First observed

TDQS

B3.4/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the mutation profile is covered; the description adds real value by disclosing the 402 media_storage_full response shape (used_bytes, limit_bytes, next_step) and the workspace_inactive lapsed-plan condition. The one blemish is that the description says 'the raw bytes as the body' while the schema requires base64 in a data_base64 field, an internal inconsistency the agent may trip on.

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 focused sentences with the core purpose front-loaded and error semantics compressed into the second. No padding, though the second sentence is dense and mixes two distinct error conditions without much connective structure.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 9 parameters, no output schema, and destructive annotations, the description could say more about what is created (media ID, previews) and how the body vs data_base64 should be supplied. It is adequate on failure modes but incomplete on the happy-path contract.

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 78%, so most parameters (width, height, duration, workspace, data_base64, content_type, idempotency_key) are already documented in the schema. The description adds no parameter-level meaning beyond that, which is the baseline case when the schema does the heavy lifting.

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 (upload) and enumerates the accepted resources (photo, video, PDF, SRT captions), so the agent knows exactly what the tool does. It does not explicitly contrast with siblings like createPost or createDraft, but the media-upload scope is distinctive enough to be separable.

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

Usage Guidelines2/5

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

There is no statement of when to use this tool versus alternatives (e.g., createDraft, createPost, callWriteOperation) and no prerequisites such as acquiring the bytes or a media ID before posting. Only failure-mode context is provided, leaving usage selection to inference.

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

All Flaghand 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