Skip to main content
Glama
Rustysama

Postfjord

by Rustysama
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Hybrid

Upload media

postfjord_upload_media

Upload a picture or video to the media library and get its ID for use in Postfjord drafts or posts. Send a public URL or local file path; scheduling waits until processing is ready.

Instructions

Adds a picture or video to the media library and returns its id, to use in mediaIds of postfjord_create_draft or postfjord_update_post. Send url (a public https address Postfjord downloads) or path (a file on this computer, at most 30 MB; send a bigger video as a url). JPEG, PNG, WebP, GIF, MP4 or MOV; a picture at most 50 MB, a video at most 500 MB, within the plan's storage. The file is processed after it arrives: status is processing until postfjord_get_media says ready. A draft can use the id right away; scheduling waits until it is ready. Nothing is posted. On a retry after a timeout or error, send the same idempotency_key: the first answer comes back and nothing is made or sent twice.

Input Schema

NameRequiredDescriptionDefault
altNoAlt text: what the picture shows, for people who cannot see it.
urlNoThe http(s) address of the file. It must answer with the file itself, not a web page about it.
nameNoThe file name to show in the library. Left out, the name comes from the address or the file.
pathNoThe full path of a file on this computer, instead of url.
idempotency_keyNoYour own id for this one action, for example post-20261006-launch. Make a new one for each new thing; send the same one again only when you retry. Left out, the exact same call within 10 minutes counts as a retry.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

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: discloses asynchronous processing ('status is processing until postfjord_get_media says ready'), the consequence for scheduling ('scheduling waits until it is ready'), storage/plan limits, accepted formats, and that 'Nothing is posted.' The retry/dedup behavior refines idempotentHint=false rather than contradicting it.

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?

Front-loaded with purpose and downstream use, then limits, then lifecycle, then retry. No filler sentences, though the density and run-on punctuation make it slightly harder to scan than an ideal definition.

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?

No output schema exists, and the description supplies the essential return (the id), its lifecycle state, and how the id is consumed by downstream tools, so an agent has everything needed to call it and handle the result.

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 3 is the baseline, but the description adds real meaning: url must be a public https address that the service downloads, path is the local-file alternative with a 30 MB cap, and idempotency_key is explicitly a per-action key reused only on retry.

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 ('Adds a picture or video to the media library') and immediately names the return value ('returns its id'), which separates it from siblings like postfjord_list_media, postfjord_get_media and postfjord_resize_media that also touch media.

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?

Explicitly routes the output to 'mediaIds of postfjord_create_draft or postfjord_update_post', tells the agent which input mode to pick (path for local files up to 30 MB, url for bigger videos), and gives the retry protocol: resend the same idempotency_key after a timeout or error.

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

Deploy Server

Other Tools