Skip to main content
Glama

Schedule posts

schedule_posts
Idempotent

Schedule one or more finished social posts that the user already has: their own media, captions, and publish times.

Each post needs post_at (ISO 8601), channels, and media. Each channel names a provider (instagram, facebook, linkedin, x, google_business_profile, tiktok, youtube) and an optional caption; a channel without a caption uses the first channel's caption. Several channels make one cross-post that shares the same media and publish time.

Media is either images (one, or several for a carousel in the order given) or exactly one video, never both. TikTok and YouTube accept video only. Media type is read from the URL extension unless you pass type. Each url must be publicly reachable; for local files, call get_media_upload_urls first.

A post with a connected social account is scheduled and publishes automatically at post_at; any of its channels without a connected account will not publish and are listed in the response. A channel whose account has lost access is flagged with a warning: it will fail to publish until the account is reconnected in Blaze (list_connected_accounts shows each account's status). A post with no connected account, or in a workspace that requires approval, is saved as a draft instead. Invalid posts (missing media, mixed images and video, too many images for a channel, bad date, no channels) are skipped and listed in the response; the others are still scheduled.

Retries: give each post an idempotency_key (any unique string) to make retries safe. If the same workspace sends the same key again within 24 hours, the post created the first time is returned and nothing new is created. Without a key, a post identical to one this tool created in the last 10 minutes (same post_at, channels, captions, and media URLs) is also returned instead of being created again; to schedule a true duplicate inside that window, pass a new idempotency_key.

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": {
      "workspace_key": "<workspace_key>",
      "posts": "<posts>"
    },
    "name": "schedule_posts"
  }
}

Input Schema

NameRequiredDescriptionDefault
postsYesThe posts to schedule. Each is scheduled independently.
workspace_keyYesKey of the workspace to act in. Call list_workspaces to see the workspaces you have access to and their keys.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

The description goes well beyond the annotations (readOnly=false, idempotent=true, openWorld=true): it discloses the draft fallback when no account is connected or approval is required, per-channel skip/warning behavior for detached or re-authentication-needed accounts, and the exact idempotency semantics (24h key window, 10-minute identical-post dedup) that operationalize the idempotentHint. That is exactly the context annotations cannot carry.

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 front-loaded with what the tool does and what a post needs, then layers prerequisites, account behavior, and retries. The content is dense and mostly earns its place, though the four-paragraph length is longer than strictly necessary and a few rules could be tightened.

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 still tells the agent what comes back (skipped/invalid posts and unpublished channels are listed in the response), and it covers permissions/approval behavior, media constraints, and idempotency. Nothing an agent needs to call this correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Even at 100% schema coverage, the description adds cross-field rules the schema cannot express: caption inheritance from the first channel, media ordering for carousels, 'one video or images, never both', TikTok/YouTube video-only, type inference from URL extension, and the idempotency_key retry contract. This meaningfully reduces misuse risk.

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+resource ('schedule one or more finished social posts') and immediately scopes it to content the user already has (their media, captions, publish times), which cleanly separates it from generation siblings like generate_post and from publish_post_now. An agent can identify the tool's job 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?

It gives concrete prerequisites and routing: call get_media_upload_urls for local files, list_connected_accounts to check account status, and it explains when a post becomes a draft rather than publishing. It does not explicitly name publish_post_now as the alternative for immediate publishing, so the alternatives set is incomplete.

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.