Skip to main content
Glama

Publish a post now

create_post

Create and publish a post to one or more social media platforms immediately.

Octopost handles formatting, auth and uploads. Which networks work today is in the server instructions (and get_guide topic "platforms").

PLATFORM CONTENT LIMITS (checked before anything is published: if the text or any segment is too long for one of the networks, the call fails with the count and nothing goes out):

  • Twitter/X: 280 chars (URLs count as 23 chars). Can't mix video with images.

  • Bluesky: 300 graphemes. Octopost auto-generates link facets.

  • LinkedIn: 3,000 chars.

  • Threads: 500 chars.

  • Mastodon: ~500 chars (varies by server; checked when publishing).

TIPS:

  • If a platform fails, the post still succeeds on other platforms — check the response for per-platform results.

  • A slow publish (Threads with media can take minutes) answers after ~20 s with status "publishing" and carries on: check it with get_post. Pass an idempotency_key; if a call times out with no postId, retry with the same key (you get the original post, never a second).

  • Use cross_link_enabled + primary_platform to post to one platform first, then share the link on others.

  • Polls are supported on Twitter (2-4 options, 5 min to 7 day duration) and Mastodon.

APPROVAL: if the account requires approval for every post (an owner setting), create_post saves the post as pending_approval instead of publishing and the result says so. Tell the user to approve it from the email Octopost sends; don't approve it yourself. To ask for a review yourself, use queue_post or schedule_post with needs_approval=true.

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": {
      "content": "<content>",
      "platforms": "<platforms>"
    },
    "name": "create_post"
  }
}

Input Schema

NameRequiredDescriptionDefault
pollNoCreate a poll. Only works on Twitter and Mastodon.
tiktokNoRequired for TikTok. Ask the user; no defaults.
contentYesThe post text. Keep under 280 chars if posting to Twitter.
accountsNoOptional. Which connected account to post as when a platform has more than one, e.g. {"twitter": "@handle"}. Values: the handle, or the id from list_accounts. Leave out to use the platform's default account (marked default in list_accounts).
segmentsNoOptional thread reply segments (up to 24). Each becomes a reply in a chain on X/Threads/Bluesky/Mastodon; on LinkedIn the first post goes out with `content` and each segment is added as a comment on it. The whole thread publishes atomically. Canonical use case: put the main message in `content` and a URL in `segments: [{content: "https://..."}]` so the link gets attached as a reply — this avoids the algorithmic down-rank that standalone link posts get on Twitter and Threads.
variantsNoOptional. A different version of the post for some networks, keyed by network, e.g. {"linkedin": {"content": "A longer take for LinkedIn"}, "twitter": {"content": "Short version", "segments": [{"content": "https://example.com"}]}}. Each network listed gets its own content, segments and/or media_urls; anything it leaves out comes from the main post (segments: [] = a single post there, media_urls: [] = no media there). Every other network gets the main post. Each version is checked against the limit of its own network. Networks must also be in platforms. With cross_link_enabled only the version for the primary network is used.
platformsYesWhich platforms to post to. Call list_accounts first to see what's connected.
video_urlNoOptional video URL. Can't be combined with images on Twitter.
media_urlsNoOptional images (up to 4 for most platforms) or one video. Must be publicly reachable. Each item is a URL string or {url, alt} with alt text (recommended for images). For a file on your machine, call create_upload first.
first_commentNoOptional. Posted as the first reply right after the post (after the last segment of a thread): a reply on X, Bluesky, Mastodon and Threads, a comment on LinkedIn. Good for the link or the hashtags. Same length limits as the post (LinkedIn comments: 1,250). Its result is reported per network as results.<network>.firstComment and never changes whether the post itself counts as published.
allow_duplicateNoOptional. Octopost refuses the same text to the same network within 7 days (the error names the earlier post). Set true only when posting it again is intended.
content_warningNoMastodon spoiler text / content warning. Post content will be hidden behind this text. Important in Mastodon culture for sensitive topics.
idempotency_keyNoOptional. A unique string (e.g. a UUID) for this post. Retry a timed-out call with the same key and Octopost returns the original post instead of posting again.
primary_platformNoWhich platform to post to first when cross_link_enabled is true. The post URL from this platform is shared to the others.
cross_link_enabledNoEnable cross-link publishing. Posts to primary_platform first, then shares the link to other platforms using the cross_link_template.
cross_link_templateNoTemplate for cross-link posts on secondary platforms. Variables: {platform} (primary platform name), {link} (post URL). Default: "New post on {platform}: {link}".
mastodon_visibilityNoMastodon post visibility. "public" = visible to all, "unlisted" = not on public timelines, "private" = followers only, "direct" = mentioned users only. Default: public.

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?

Far beyond the annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false): it discloses pre-publish length validation with atomic failure and no partial output, per-platform failure isolation, ~20s timeout handing off to status "publishing", duplicate-text refusal within 7 days, and the approval gate that leaves the post as pending_approval. The idempotency_key retry contract is spelled out, which usefully qualifies idempotentHint=false.

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 purpose sentence followed by clearly labeled LIMITS / TIPS / APPROVAL blocks, so an agent can skim to what it needs. The platform limit list and tips are dense but each item changes a decision; only the length-tracking repetition costs it the top score.

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 17-parameter, deeply nested, no-output-schema mutation tool, the description covers the failure modes, async behavior, and approval path an agent needs to act safely. It could say a bit more about what a successful response contains (postId, results.<network>) beyond the firstComment note, but the gaps are minor.

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; the description adds real meaning on top by giving per-network character/grapheme limits, the cross_link_enabled + primary_platform sequencing, and poll support constraints. It does not explain less common params such as variants fallback rules or first_comment semantics, leaving some of that to the already-rich schema.

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?

Opens with a specific verb and resource ('Create and publish a post') plus an immediacy qualifier ('immediately') that separates it from queue_post / schedule_post, which are named later in the approval section. An agent can identify the tool and its scope 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 Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes the agent elsewhere: get_guide topic "platforms" for availability, list_accounts before choosing platforms, get_post for slow publishes, and queue_post / schedule_post with needs_approval=true when a review is wanted. It also states when this tool is the wrong choice (approval-required accounts get pending_approval instead of a publication).

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