Posteady

Create a media upload

create_media_upload

Create a temporary URL to PUT media into the workspace. mediaType defaults to VIDEO and accepts MP4/MOV up to 2 GiB; IMAGE accepts .jpg/.jpeg/.jfif with image/jpeg up to 8 MiB. The file itself is uploaded to the returned URL with requiredHeaders within expiresInSeconds; confirm_media_upload then makes it publicly accessible via its media URL. This tool takes file details only and does not publish a social media post.

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>",
      "fileSize": "<fileSize>"
    },
    "name": "create_media_upload"
  }
}

Input Schema

Name	Required	Default
`fileName`	Yes
`fileSize`	Yes
`mediaType`	No	VIDEO
`contentType`	Yes
`workspaceId`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 4, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Beyond the annotations (readOnly=false, openWorld=true, non-idempotent, non-destructive), the description discloses the temporary nature of the URL, the expiry window, the hard size ceilings (2 GiB video / 8 MiB image), and that the media stays private until confirm_media_upload runs. It does not say that each call mints a new URL, which is the practical consequence of the non-idempotent hint.

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?

Three sentences, front-loaded with the verb and the return artifact, with the constraint detail packed into the supporting clauses. Dense but no filler; the negative statement about publishing is deliberately placed last.

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

Completeness4/5

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

There is no output schema, and the description compensates by naming the return payload (URL, requiredHeaders, expiresInSeconds), which is exactly what an agent needs to finish the flow. The only material gap is workspaceId, which the description neither explains nor mentions.

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?

With 0% schema description coverage the description must carry parameter meaning, and it does explain mediaType's VIDEO default, the accepted image extensions, and the size caps behind fileSize. However workspaceId is never mentioned, and contentType is only implied through the mime-type/size pairing, so an agent must infer part of 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?

"Create a temporary URL to PUT media into the workspace" states a specific verb, resource and output artifact, which is immediately distinguishable from confirm_media_upload and publish_post in the sibling list. The final sentence explicitly disclaims social publishing, removing the ambiguity an agent could have with publish_post.

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 a clear usage sequence (call this, PUT the bytes to the returned URL with requiredHeaders before expiresInSeconds, then call confirm_media_upload) and states what the tool does not do (publish a post). What is missing is an explicit "use X instead when..." for cases where a pre-signed upload is not needed.

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

All Posteady 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?