postmoderno

Create media upload URL

create_upload_url

Get a PUT URL to attach a local media file to a draft post. The response includes max_size_bytes, enforced while uploading for every file and plan. With size_bytes, an oversized file is refused before uploading, and a body of any other size is refused instead of checked as a whole file. The file's bytes go up with the headers in the response, as its note shows; the file is checked as it arrives, and the reply gives the size and sha256 stored. Refused once the post or its chain is scheduled, because the user has approved its media; canceling the post allows more.

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": {
      "post_id": "<post_id>",
      "mime": "<mime>"
    },
    "name": "create_upload_url"
  }
}

Input Schema

Name	Required	Description
`mime`	Yes	media mime type, e.g. image/png or video/mp4
`post_id`	Yes	draft post to attach the media to
`alt_text`	No	accessibility description
`size_bytes`	No	the file's size in bytes, when known: refuses an oversized file now, and any upload of another size later

Output Schema

Name	Required	Description	Default
`note`	Yes
`headers`	Yes
`media_id`	Yes
`upload_url`	Yes
`max_size_bytes`	Yes
`expires_in_seconds`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 7, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations only say this is a non-idempotent, non-destructive write; the description adds real behavior — a max_size_bytes cap enforced for every file and plan, pre-upload refusal when size_bytes is supplied, refusal of mismatched body sizes, streaming validation with a returned size and sha256, and the scheduling lockout. Some of the phrasing ('a body of any other size is refused instead of checked as a whole file', 'as its note shows') is murky enough that the exact upload contract is not fully unambiguous.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The opening sentence is well front-loaded, but the middle section is dense and awkward — 'a body of any other size is refused instead of checked as a whole file' and 'as its note shows' cost the reader effort without adding precision. Several clauses could be tightened into a compact upload contract.

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?

For a four-parameter write tool with full annotations and an output schema, the description covers the essential operational facts: size limits, pre-validation, upload mechanics, checksum confirmation, and the scheduled-post lockout. Only the exact sequencing relative to schedule_post and the precise request/response contract remain under-specified.

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?

Schema coverage is 100%, so all four parameters are already documented, including size_bytes' dual role. The description restates the size_bytes refusal behavior almost verbatim from the schema and adds no new syntax, format, or interaction detail for mime, alt_text, or post_id. Baseline 3 applies when the schema carries the parameter burden.

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 — 'Get a PUT URL to attach a local media file to a draft post' — which no sibling tool (create_post, edit_post, schedule_post) covers. An agent can identify this as the media-attachment step without opening the schema.

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?

Gives a clear when-not condition: the call is refused once the post or its chain is scheduled, and canceling the post re-enables it. It stops short of naming the alternative flow (e.g., that this must precede schedule_post or that edit_post handles other post changes), so guidance is contextual rather than exhaustive.

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

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