Skip to main content
Glama

upload_media

Upload media to the library. Three methods supported:

  1. url — import from a PUBLIC https URL (e.g. a hosted image link). NEVER pass a local sandbox path — the URL must be reachable from our servers.

  2. base64_data — pass base64-encoded file data directly. ONLY use this for tiny files (≲50 KB). MCP tool inputs are token-capped — anything larger gets silently truncated and uploads a corrupted file. For any user-pasted image, use upload_url instead.

  3. upload_url — PREFERRED for any file the user attached to the chat. Call with method="upload_url" to get a one-time presigned URL plus a ready-to-run snippet. Execute the snippet in your code-execution tool against the actual file path. The response JSON contains the media id you pass to create_post.

Size limits: base64/direct uploads are capped at 100 MB. For anything larger — up to 1 GB — use a public url (fetched server-side, bypasses the cap), OR have the user upload the file in the OmniSocials Library UI at https://app.omnisocials.com/library . IMPORTANT: if the user has a large LOCAL file (over ~100 MB) with no public url, do NOT tell them to compress it — point them to the Library UI link above. Large videos (over 100 MB) are processed in the background — the response status is "processing" and the file is NOT usable in a post until it becomes "ready" (re-check with list_media).

Compatibility: every upload response includes a "compatibility" summary of any CONNECTED platforms that would reject the file (e.g. too large for Instagram). If there are warnings, RELAY them and ask the user whether to continue before posting — the file still uploads and can post to platforms that accept it. To check BEFORE uploading, call check_media_compatibility first.

PDF = carousel: upload a PDF (via a public url, or base64_data with mime_type "application/pdf", or the upload_url snippet) and it is split into one image slide per page (max 20). The response lists a Media ID for EVERY slide — pass ALL of them, in order, as media_ids to create_post to post the deck as a carousel. On LinkedIn the slides post as a native swipeable DOCUMENT made from the ORIGINAL PDF file (the file is kept: text stays sharp, in-document links work, viewers download the real file, and every page is included even past the 20-slide cap) as long as the slides are posted unchanged and in order; on Instagram, TikTok, Threads and Pinterest as an image carousel. Set linkedin.document_source to 'slides' on the post to send a document rebuilt from the slide images instead. This is how a user posts an existing slide deck (Canva/PowerPoint/Figma exported to PDF) as a carousel. Prefer pdf_mode "document" when the user wants ONE library item for the deck (no per-page clutter): the response then has a single Media ID whose media_ids entry expands into every page at post time.

Supported: JPEG, PNG, GIF, WebP, MP4, MOV, AVI, PDF.

For user-attached files: ALWAYS try upload_url first. Call upload_media with method="upload_url", then in your code-execution sandbox run the returned Python (ChatGPT Code Interpreter, file at /mnt/data/) or curl (Claude Code Execution) snippet against the actual file path. Only react to a failure AFTER actually executing the snippet.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlNoPublic URL of the media file (method=url). Use this when the user pasted an image link or you generated one via DALL·E.
fileNoOpenAI Apps SDK file reference. Set when the user attached a file in ChatGPT — the platform fills this in automatically.
nameNoHuman-readable label so you can find this asset by name later instead of re-uploading it, e.g. "pp-play5get50". Strongly recommended on every upload.
folderNoOptional folder name to file this asset under (created at the top level if it does not exist), e.g. "win-graphics". Use list_folders to see existing folders.
methodNoUpload method: "file" (ChatGPT user-attached image — preferred), "url", "base64_data", or "upload_url". Auto-detected from which arg you pass.
filenameNoOptional filename with extension
pdf_modeNoPDF uploads only. "slides" (default): one image media item per page, one Media ID each (pass ALL of media_ids to create_post). "document": ONE media item for the whole PDF (type "document"); pass its single Media ID in media_ids and the post gets every page in order. Both keep the original file, which LinkedIn receives. For method="upload_url", send it as a form field: -F pdf_mode=document.
mime_typeNoMIME type (e.g. 'image/jpeg'). Required for base64_data and upload_url.
base64_dataNoBase64-encoded file data (method=base64_data). Only safe for files <50 KB.

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 declare only readOnlyHint=false, openWorldHint=true, destructiveHint=false. The description adds substantial non-obvious behavior: token-cap truncation on base64, the 100 MB/1 GB size ceilings, background 'processing' status for large videos, compatibility warnings, PDF page-splitting, and LinkedIn document preservation. These are exactly the traits an agent cannot infer from annotations.

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?

Front-loaded and well-organized with a numbered method list and labeled sections (size limits, compatibility, PDF, supported formats). It is long but largely justified by the 9-parameter, multi-method surface; the only cost is mild repetition of the 'always try upload_url first' guidance.

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 no output schema, the description carries the burden of describing returns and does so thoroughly: media id, compatibility summary, 'processing' status with list_media re-check, and per-slide media_ids. Given the tool's complexity and nested file object, nothing critical appears missing.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds genuine operational semantics beyond the schema: it explains method selection, warns that base64 silently truncates above ~50 KB, and clarifies pdf_mode 'slides' vs 'document' downstream effects. It slightly exceeds the baseline by tying parameter choices to failure modes.

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?

Opens with a precise verb+resource ('Upload media to the library') and immediately enumerates the three supported input methods with concrete examples. It clearly distinguishes itself from siblings like list_media, delete_media, and update_media, and even names check_media_compatibility and create_post as adjacent steps.

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?

Explicitly states when to use each method (url for public links, base64 for tiny files, upload_url for user-attached files), gives a clear preference order, and names conditions and alternatives (check_media_compatibility before uploading, Library UI for >1 GB local files, do NOT compress). This is textbook 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.

Resources