Skip to main content
Glama

Create Post

create_post

Creates one post for X, LinkedIn or Threads and saves it as a draft (status=draft) with an optional proposed time; nothing is scheduled or published until confirm_post approves it. platform=bluesky or mastodon returns an error and saves nothing, because publishing to them isn't available yet. A scheduled_date is stored as the proposed publish time. Without one, and with auto_slot on (the default), Handler proposes the next open slot inside the founder's posting window for that platform, honoring daily caps (5 X / 3 Threads / 2 LinkedIn per day) and spacing (90min / 2h / 4h); the response's slot_assignment holds the proposed time and a rationale string. auto_slot: false saves a dateless draft. With an idempotency_key, a retry with the same key replays the original response instead of creating a duplicate. Multi-part threads (X and Threads): parts separated by a line containing only --- publish as one thread, one part per post; without ---, the content publishes as a single post. X allows 280 characters per post; a longer single post needs the founder-confirmed X long-post setting and an account that supports it, and FeedSquad never splits it into a thread. A thread exists only with --- on its own line between parts, and every part must be 280 characters or fewer. Content is capped at 3,000 characters. Every response carries status_before, status_after and approval_required.

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

Input Schema

NameRequiredDescriptionDefault
titleNoOptional title for the post
contentYesThe post content (max 3000 characters)
dry_runNoWhen true, the call validates inputs and checks capacity without writing, and returns what would happen.
platformNoTarget platform: linkedin, x (twitter is an alias), or threads. bluesky and mastodon are accepted for compatibility but return an error: publishing to them isn't available yet.linkedin
auto_slotNoWhen true (default) and scheduled_date is omitted, Handler proposes the next available slot, honoring per-platform daily caps (5 X / 3 Threads / 2 LinkedIn) and spacing (90min / 2h / 4h); the post is saved as a draft with that proposed time. false keeps the post as a dateless draft (no proposal).
campaign_modeNoActivates Handler campaign mode: spacing rules are relaxed for 48 hours (a launch-day override). Daily caps stay enforced (5 X / 3 Threads / 2 LinkedIn). While the window is active, later auto-slotted posts inherit the relaxation.
scheduled_dateNoOptional future publish time to propose, ISO 8601. With an offset or Z it is used exactly as sent; without one (e.g. 2026-10-22T08:45) it is read in the founder's timezone (the timezone field of scheduling responses) and the response's time_input says so. The time is kept exactly as given, to the minute. The post is saved as a draft either way; the time is committed only when the draft is approved. When omitted, auto_slot decides whether Handler proposes a slot.
company_page_idNo
idempotency_keyNo
connector_account_idNo

Output Schema

NameRequiredDescriptionDefault
kindYes
quotaNo
titleNo
healthNo
noticeNo
statusYes
contentYes
dry_runNo
draft_idYes
platformYes
timezoneNo
char_countYes
server_nowNo
time_inputNo
status_afterNo
would_createNo
campaign_modeNo
dashboard_urlNo
status_beforeNo
approval_resetNo
scheduled_dateNo
scheduled_localNo
slot_assignmentNo
timezone_sourceNo
approval_requiredNo

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?

Annotations only say non-read-only and non-destructive; the description adds substantial context beyond them: nothing is scheduled or published, daily caps (5 X / 3 Threads / 2 LinkedIn) and spacing rules apply, campaign_mode-adjacent behavior, replay-on-retry with idempotency_key, and the status_before/status_after/approval_required fields every response carries. The conditional idempotency is consistent with 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.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded well and dense with useful rules, but it is one long undifferentiated paragraph with real duplication: the X 280-character limit is stated twice in different sentences, and the '---' thread rule is restated ('publish as one thread' then 'A thread exists only with ---'). Splitting into short labelled chunks would make the same content far easier to scan.

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?

For a 10-parameter mutation tool with an output schema present, this covers everything material: what is written, what is deferred to approval, platform limits, thread structure, slotting policy, retry safety, and response fields. No gap an agent would need to fill from another tool.

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?

With 70% schema coverage the schema does much of the work, and the description partly restates it (content cap, auto_slot default, scheduled_date timezone handling). It still adds schema-absent meaning, most importantly the '---' on its own line thread-separator syntax and the per-part 280-character rule, which an agent could not infer from the input 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, resource, and scope: creates ONE post, for X/LinkedIn/Threads, and saves it as a draft rather than publishing. That immediately separates it from the plural create_posts, from publish_post, and from confirm_post, which the description names as the approval gate.

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?

Gives explicit when/when-not rules: bluesky and mastodon are rejected, auto_slot decides slotting when scheduled_date is omitted, idempotency_key protects against duplicate retries, and confirm_post is the tool that actually approves/publishes. The agent knows both the happy path and the failure path before calling.

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