Skip to main content
Glama

Postlyra.app — Telegram posts from AI chats

Prepare a media upload

create_media_upload

Use when uploading a local image, video, document, audio or voice file from any MCP client. Returns a short-lived PUT URL, headers and uploadIntentId. Upload the actual bytes, then call finalize_media_upload. A local filesystem path cannot be read by the server.

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": {
      "fileName": "<fileName>",
      "contentType": "<contentType>",
      "sizeBytes": "<sizeBytes>"
    },
    "name": "create_media_upload"
  }
}

Input Schema

NameRequiredDescriptionDefault
categoryNoMedia kind: image, animation, video, audio, voice or document. Omit to infer from MIME type.
fileNameYesOriginal filename including extension, e.g. report.pdf.
sizeBytesYesExact positive file size in bytes; upload those bytes before finalizing.
contentTypeYesActual file MIME type, e.g. image/png or application/pdf.

Output Schema

NameRequiredDescriptionDefault
dataYes
messageYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedInput schema / properties / category / description
      Added value: +"Media kind: image, animation, video, audio, voice or document. Omit to infer from MIME type."
    • addedInput schema / properties / contentType / description
      Added value: +"Actual file MIME type, e.g. image/png or application/pdf."
    • addedInput schema / properties / fileName / description
      Added value: +"Original filename including extension, e.g. report.pdf."
    • addedInput schema / properties / sizeBytes / description
      Added value: +"Exact positive file size in bytes; upload those bytes before finalizing."
  2. Changed1 schema field changed
    • changedInput schema / properties / category / enum
      Previous value: -[
      -  "image",
      -  "animation",
      -  "video",
      -  "document"
      -]New value: +[
      +  "image",
      +  "animation",
      +  "video",
      +  "audio",
      +  "voice",
      +  "document"
      +]
  3. First observed

TDQS

A4.3/5.0
Behavior4/5

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

The description adds meaningful behavior beyond annotations: it returns a short-lived PUT URL, headers, and uploadIntentId; the caller must upload actual bytes; then finalize. It also clarifies a server limitation around local filesystem paths. It does not discuss auth, expiration handling, or failure behavior, but the annotations already cover safety hints.

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?

The description is four tight sentences, front-loaded with the usage condition and workflow. Every sentence contributes either selection guidance, return information, sequencing instructions, or a key constraint.

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 two-step upload tool, the description covers the trigger condition, returned artifacts, required follow-up call, and an important local-path constraint. With a full input schema and an output schema, no essential agent-facing context appears to be 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 the schema already documents all four parameters thoroughly, including the category enum and examples. The description reinforces the local-file and actual-bytes requirement but does not add parameter-specific meaning beyond 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?

The description states a specific action and resource: preparing a media upload for local files. It clearly distinguishes this step from finalize_media_upload by describing the two-step workflow and what this tool returns.

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?

It gives clear usage context: use when uploading local image, video, document, audio, or voice files from any MCP client, then call finalize_media_upload. It also warns that a local filesystem path cannot be read by the server. It does not explicitly compare against sibling tools such as attach_media, so it stops short of full when/when-not guidance.

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.