Skip to main content
Glama
Rustysama

Postfjord

by Rustysama
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Hybrid

Create draft or scheduled post

postfjord_create_draft

Creates a new social post for one or more channels, saved as a draft or scheduled for publishing at a set time. Use it to write content once and validate it per channel before it goes out.

Instructions

Makes one new post. To put a time on a draft that already exists use postfjord_schedule_post, to change one post postfjord_update_post, to move or remove many posts postfjord_bulk_update_posts. Without scheduledAt it is saved as a draft (validation problems are returned so you can fix them). With scheduledAt it must pass validation and becomes scheduled: the engine publishes it at that time. Check the brand profile and channel limits first. Instagram requires at least one image or video (mediaIds from postfjord_list_media). Send dry_run: true first to check a post before it is scheduled. Pictures: every channel sends its own shape. Before scheduling, call postfjord_preview_post and show the person the picture of each channel. Where a crop would cut off a person (a head, hands, feet) or words in the picture (a poster, a menu, a quote), set that picture's fit to { mode: "whole" } in targets, or move focus to what must stay, then preview again. 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
linkNoURL for platforms that support links in the text.
intentNogive: the post helps, teaches or entertains. ask: it asks people to buy, book, sign up or click. Left out, Postfjord labels it when it is scheduled.
pillarNoContent pillar label, for your own planning.
bioLinkNoWhere a tap on this post on your link in bio page goes. Never added to the post. On update, send it alone to change it on a published post (needs a key that may publish). An empty string removes it.
dry_runNotrue: save nothing, and answer what would be made: draft or scheduled, the channels, the time in the workspace time zone, the problems and what would refuse it (ok, blockers).
targetsNoPer-channel overrides keyed by channel id.
baseTextYesThe post text used on every channel unless overridden in targets.
mediaIdsNoIds from postfjord_list_media, in display order.
videoPageNofalse: this video gets no video page on postfjord.page when it goes out. Left out, the workspace setting decides (see postfjord_list_pages, videoPages).
channelIdsYesIds from postfjord_list_channels. May be empty for a draft; scheduling needs at least one.
scheduledAtNoISO 8601 date-time with its time zone offset, e.g. 2026-09-10T08:00:00-04:00. A time without one is refused.
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.7/5.0
Behavior5/5

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

Goes well beyond the annotations: without scheduledAt it saves a draft and returns validation problems; with scheduledAt it must pass validation and the engine publishes at that time. It also discloses the idempotency contract for retries after timeouts, including the default 10-minute same-call window, which is real behavioural information the annotations (idempotentHint=false) do not convey.

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?

The critical discriminator (what it makes, and which sibling to use instead) is front-loaded, and most sentences carry an operational rule. It is long, though, and a few clauses (the crop/"whole" explanation) restate what the target schema already documents, which slightly dilutes the signal.

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 12-parameter, nested-object mutation tool with no output schema, the description covers the main modes, prerequisites, idempotency, and what dry_run returns. It is thinner on what a successful non-dry-run creation returns and on permission requirements, which matters for a tool that can schedule real publishing.

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 the baseline is 3, but the description adds cross-parameter semantics: the presence/absence of scheduledAt switches draft vs scheduled mode, mediaIds come from postfjord_list_media, and targets.fit mode "whole" is the remedy when a crop would cut people or words. Some of this (the fit modes) duplicates the schema text.

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?

"Makes one new post" gives a specific verb and resource, and the second sentence names three sibling tools (schedule_post, update_post, bulk_update_posts) with the exact case each covers. An agent can distinguish this tool from its neighbours without opening any schema.

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: existing drafts go to schedule_post, single edits to update_post, batch moves/removals to bulk_update_posts. It also states prerequisites (check brand profile and channel limits, Instagram needs an image or video, dry_run first, preview before scheduling) rather than leaving ordering to inference.

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