Ravenpost

Upload media

upload_media

Upload an image or a video (mp4/mov/webm) to the media library, returning a media id for create_post. Each call adds a new asset to this workspace’s private library; nothing already there is replaced, and nothing is posted anywhere. Images are reformatted to the requested publishing format; videos are stored as-is (format/fit are ignored — upload the video pre-edited). Give the file as ONE of: url (preferred when it is already online — the server downloads it from whatever public address you give) or base64 (fallback for small images; avoid for video). For a large local file in production, prefer create_media_upload (direct upload, no base64 through this channel). format: feed_square (1:1), feed_portrait (4:5), landscape (1.91:1), story or reel (9:16), or original (no resize). fit: "cover" crops to fill (default), "contain" fits the whole image and pads.

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": {
      "format": "<format>"
    },
    "name": "upload_media"
  }
}

Input Schema

Name	Required	Description
`fit`	No	cover = crop to fill (default), contain = fit + pad
`url`	No	Public URL to fetch the file from (preferred if already online)
`crop`	No	How a 'cover' crop chooses what to keep: 'smart' = saliency-based, keeps the subject (default); 'centre' = predictable middle crop, better for posters/screenshots
`base64`	No	Base64 file bytes (data URI ok) — fallback for small images; avoid for video
`format`	Yes	Target format / aspect ratio (images only — videos are stored as-is)
`workspaceId`	No	Which workspace to act in — an id from list_workspaces. Optional with a single workspace; REQUIRED once there are several, where guessing would mean posting one client's content to another client's accounts. Ask the user which one before publishing.

Output Schema

Name	Required	Description	Default
`ok`	No
`note`	No
`media`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 1, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the annotations: it discloses that each call only appends to a private library with no replacement and no publishing, that images are reformatted while videos are stored untouched, and that the server fetches the file from whatever public address is given (consistent with openWorldHint=true). This is exactly the context an agent needs before a non-idempotent, network-fetching write.

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?

Purpose and return value are front-loaded, and nearly every clause carries operational information. It is a dense single block, though, and the format/fit enumeration could be tightened given the schema already lists the enums.

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 6-parameter upload tool with an output schema, the description covers source options, format semantics, mutation scope, and the sibling alternative for large files. Nothing an agent needs in order to call it correctly is 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 already 100%, so the baseline is 3, but the description adds real meaning: it maps format enum values to concrete aspect ratios, explains the cover/contain tradeoff, and warns that format/fit are no-ops for video. The only gap is that the crop parameter is left entirely to 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?

States a specific verb and resource ("Upload an image or a video ... to the media library") and immediately gives the downstream purpose ("returning a media id for create_post"), which distinguishes it from create_media_upload, attach_media, and create_video. Supported types (mp4/mov/webm) are named explicitly.

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?

Explicit routing rules: use url when the file is already online, base64 only as a fallback for small images and to avoid for video, and "prefer create_media_upload" for large local files. It also tells the agent when format/fit are ignored (videos) and enumerates the format choices with their aspect ratios.

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

All Ravenpost 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.