posterly

upload_media

Destructive

Upload an image or video to posterly storage and get a URL for create_post; nothing is published. base64_data with filename: small files (<=5MB decoded). url: copy a public HTTPS image or video. Larger files: create_signed_upload, then PUT the bytes. JPEG, PNG, GIF, WebP, MP4, MOV, WebM; counts against storage quota. No PDFs here: use create_signed_upload or create_media_drop. asset_id (from list_media) deletes that library file after a preview. A file a post still uses is kept.

Input Schema

Name	Required	Description
`url`	No	Public HTTPS image or video URL to copy into posterly storage.
`confirm`	No	Delete only: Leave out to get a preview. Set true only after the user explicitly approved it, with the preview_id.
`asset_id`	No	File id from list_media to delete, after a preview. Use alone.
`filename`	No	e.g. photo.jpg; required with base64_data.
`chat_files`	No	ChatGPT chat files, in post order.
`preview_id`	No	The preview_id from the preview call. Required with confirm: true for actions that preview first.
`base64_data`	No	Base64 file data.
`content_type`	No	MIME type (default: from filename)
`workspace_id`	No	Optional. The workspace this acts in and whose plan pays (from whoami). Needed only when your connection can act in several workspaces.

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedOct 28, 2026

changedInput schema / properties / asset_id / description

Previous value: -"Library file id from list_media. Deletes that file after a preview. Do not combine with url or base64_data."New value: +"File id from list_media to delete, after a preview. Use alone."

changedInput schema / properties / base64_data / description

Previous value: -"Base64-encoded file data. The HTTP MCP transport requires base64 (no filesystem access)."New value: +"Base64 file data."

addedInput schema / properties / chat_files

Added value: +{
+  "description": "ChatGPT chat files, in post order.",
+  "items": {
+    "properties": {
+      "download_url": {
+        "type": "string"
+      },
+      "file_id": {
+        "type": "string"
+      },
+      "file_name": {
+        "type": "string"
+      },
+      "mime_type": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "download_url"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

changedInput schema / properties / content_type / description

Previous value: -"MIME type (auto-detected from filename if omitted)"New value: +"MIME type (default: from filename)"

changedInput schema / properties / filename / description

Previous value: -"Filename with extension, e.g. photo.jpg. Required with base64_data."New value: +"e.g. photo.jpg; required with base64_data."

changedInput schema / properties / url / description

Previous value: -"Public HTTPS URL of an image or video to copy into posterly storage instead of base64_data."New value: +"Public HTTPS image or video URL to copy into posterly storage."

Changed3 schema fields changedOct 23, 2026

addedInput schema / properties / asset_id

Added value: +{
+  "description": "Library file id from list_media. Deletes that file after a preview. Do not combine with url or base64_data.",
+  "type": "string"
+}

addedInput schema / properties / confirm

Added value: +{
+  "description": "Delete only: Leave out to get a preview. Set true only after the user explicitly approved it, with the preview_id.",
+  "type": "boolean"
+}

addedInput schema / properties / preview_id

Added value: +{
+  "description": "The preview_id from the preview call. Required with confirm: true for actions that preview first.",
+  "type": "string"
+}

First observedOct 8, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already mark the tool as destructive and open-world, but the description adds substantial context beyond them: uploads are not published, storage quota is consumed, a specific size threshold applies to base64 data, deletion requires a preview, and files still used by a post are retained. Those are meaningful behavioral details for both upload and destructive branches.

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 main purpose is front-loaded in the first sentence, followed by mode-selection guidance, format limits, and the deletion caveat. The style is dense and telegraphic, but every fragment earns its place and no sentence is redundant.

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 9-parameter tool with no output schema and a destructive deletion mode, the description covers the important workflows: small uploads, URL copies, large uploads via another tool, supported formats, quota impact, PDF exclusions, and safe deletion behavior. It gives enough context to choose the right path without opening sibling tools.

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. The description still adds useful selection semantics by mapping base64_data to small files, url to public HTTPS assets, and asset_id to the preview-then-delete flow. It does not explain every parameter, but it adds more than the schema alone for the main mode-selection parameters.

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 verb and resource: upload an image or video to posterly storage and get a URL for create_post. It also clearly discloses the secondary deletion behavior via asset_id, which prevents the agent from mistaking this for an upload-only tool. It distinguishes the tool from create_signed_upload and create_media_drop.

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?

It gives explicit routing rules: base64_data with filename for small files, url for public HTTPS copies, and create_signed_upload for larger files. It names the alternative for PDFs and explains the asset_id deletion flow after a preview. This is exactly the when-to-use guidance an agent needs.

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

All posterly tools Inspect

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

Need Help?