Skip to main content
Glama

Schedule or publish a post

create_post
DestructiveIdempotent

Creates ONE post on the given accounts of ONE social group: scheduled for later (scheduled_at), published at once (publish_now: true), or saved as a draft that goes nowhere yet (save_as_draft: true). Exactly one of the three. A post is public and goes to real accounts, so only schedule or publish when the user has given the content, the accounts and the time; when unsure, save a draft and tell the user. Every account gets caption, unless captions_by_account gives it a text of its own (a short one for X, a longer one for LinkedIn). Call get_platform_rules first when you are not sure a caption or the media fits a platform. Safe to repeat: the same caption, accounts, time and media a second time returns the post already made instead of posting twice (set allow_duplicate to really send it again).

Input Schema

NameRequiredDescriptionDefault
coverNoCustom cover for the video on Instagram, Facebook, LinkedIn and Pinterest accounts in this post. Other platforms have no cover option.
tiktokNoTikTok settings. Without this a TikTok post goes out PRIVATE with comments off, so send it for every TikTok post.
captionYesThe post text. Every account gets it unless captions_by_account names that account.
youtubeNoYouTube title, description and thumbnail. No < or > in the title, description or caption of a YouTube post.
timezoneNoIANA timezone name, e.g. Australia/Sydney. Always send it with scheduled_at; never convert to UTC yourself.
account_idsYesAccount ids from list_accounts. All of them must be in the same social group: one post goes to one group.
publish_nowNotrue = publish immediately. A post with no time is never published unless this is true, so a forgotten time cannot publish by accident.
scheduled_atNoWhen to publish, as local wall-clock time in `timezone`, e.g. 2026-10-20T18:00:00. Must be in the future. Leave out only with publish_now.
first_commentNoPosted under the post right after it publishes, by the same account, on Facebook, Instagram, Threads, X, Bluesky and Mastodon. Other platforms ignore it. get_post shows whether it was posted.
save_as_draftNotrue = only save it. Nothing is published or scheduled and no time is given; the platform rules are checked later, when publish_draft sends it. Not together with scheduled_at or publish_now.
media_file_idsNoMedia ids in display order: from import_image (an image by link), or ids of media already in the Sociro library. This server cannot take a file. Leave out for a text post.
allow_duplicateNotrue = create this post even if the identical one was already created. Only when the user asks to post the same thing again.
social_group_idNoThe social group the post is for, from list_accounts. Usually not needed: Sociro works it out from the accounts. Send it when an account belongs to more than one group, or when Sociro asks for it.
captions_by_accountNoA different text for some accounts: { "<account id>": "text" }. Each key must be one of account_ids. Each text is checked against its own platform's limits.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=true and openWorldHint=true, but the description adds substance: posts are public and hit real accounts, drafts defer platform-rule checks until publish_draft, and the idempotency key (caption + accounts + time + media) is spelled out along with the `allow_duplicate` escape hatch. That is real value beyond the hints, though it does not discuss rate limits or failure modes.

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?

It is a single dense paragraph, but it is front-loaded with the mode decision and every sentence carries operational weight. Minor redundancy: `allow_duplicate` and `captions_by_account` behavior is restated from the schema, and the long paragraph form makes scanning harder than a short bulleted mode list would.

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 14-parameter, nested-object mutation with no output schema, the description covers the critical decisions: mode selection, idempotency, platform-rule pre-checks, and caption distribution. It only lightly gestures at what comes back ("returns the post already made"), and does not mention media ordering or cover requirements, which the schema carries alone.

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 baseline is 3, but the description adds cross-parameter semantics the schema does not: the three-way exclusivity of scheduled_at / publish_now / save_as_draft, and the fallback rule that every account gets `caption` unless `captions_by_account` overrides it. Those relationship-level facts lift it above baseline.

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 ("Creates ONE post on the given accounts of ONE social group") and immediately enumerates the three mutually exclusive modes, which distinguishes it from update_post, plan_posts and publish_draft. The emphasis on ONE post / ONE group also pins down scope that a sibling like plan_posts would not have.

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 decision rules: "Exactly one of the three" modes, only schedule/publish when the user supplied content, accounts and time, "when unsure, save a draft and tell the user," and "Call get_platform_rules first when you are not sure a caption or the media fits a platform." It also routes the re-post case to `allow_duplicate` rather than a separate tool, so alternatives are named and conditioned.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources