Posthell

Get a URL to upload a photo or video

get_upload_url

Use this to post a file from the user's computer (a video you rendered, a photo). Returns uploadUrl and mediaUrl: PUT the raw file bytes to uploadUrl with its Content-Type header (the curl line in the result does it), then pass mediaUrl in the media list of create_draft or publish_post. Files are stored for good, so a draft keeps its video. Up to 50MB. Types: JPG, PNG, GIF, WebP, MP4, MOV, WebM, or PDF.

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>",
      "size": "<size>"
    },
    "name": "get_upload_url"
  }
}

Input Schema

Name	Required	Description
`size`	Yes	File size in bytes
`filename`	Yes	The file's name, e.g. reel-week-1.mp4
`contentType`	Yes	MIME type, e.g. video/mp4, video/quicktime, image/jpeg, image/png

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 23, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Beyond the annotations, the description discloses important behavior: files are stored permanently, the upload uses a PUT with the correct Content-Type, a curl example is included in the result, and there are size and type limits. These are material constraints not covered by the readOnly/destructive/openWorld 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 front-loaded with the core action and then adds only operationally necessary details: return values, upload mechanics, persistence, size limit, and file types. There is no filler or repetition.

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 explains the returned uploadUrl and mediaUrl and how to use them end-to-end. Combined with the annotations and fully described input schema, an agent has enough information to invoke this tool correctly.

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?

The schema already documents all three parameters at 100% coverage, so the baseline is 3. The description adds meaningful constraints beyond the schema: the 50MB limit, the exact supported MIME/file types, and the need to send the raw bytes with the Content-Type header.

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: get an upload URL for posting a photo or video from the user's computer. It clearly distinguishes this preparatory upload step from create_draft and publish_post, which consume the returned mediaUrl.

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 explicitly says when to use this tool ('to post a file from the user's computer'), what to do with the result (PUT raw bytes to uploadUrl, then pass mediaUrl to create_draft or publish_post), and names the downstream tools. This leaves little ambiguity about workflow placement.

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

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