Skip to main content
Glama

Create draft post

create_post
Idempotent

Create a draft post targeting one or more connected accounts. Body is validated against each target platform's limits immediately. Optional media: public image URLs with alt text, downloaded and checked right away; the schedule preview reports one still downloading or refused. Optional quote_url: the link to one post, sent as the platform's own quote, or on X as the link at the end of the text, which stays visible above X's quote card and counts toward the post's length; it is refused where a target is on another platform, cannot quote, or cannot carry a quote beside the media. A retry with the same idempotency_key returns the post already created; reusing the key with different arguments is rejected. series_key files the post as the next installment of that series. This saves a draft: scheduling is a separate step.

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": {
      "body": "<body>",
      "target_account_ids": "<target_account_ids>",
      "idempotency_key": "<idempotency_key>"
    },
    "name": "create_post"
  }
}

Input Schema

NameRequiredDescriptionDefault
bodyYesthe post text
mediaNoimages to attach, by public URL
quote_urlNolink to one post to carry as the platform's own quote, on that post's platform; list_platforms says which platforms can
series_keyNofile this post as the next installment of a series (from list_series)
idempotency_keyYesunique key for this exact creation request; generate once and pass unchanged on every retry
target_account_idsYesconnected account ids to publish to (from list_accounts)

Output Schema

NameRequiredDescriptionDefault
postYes
reusedNo
seriesNo

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?

Beyond the annotations (readOnlyHint=false, idempotentHint=true), the description discloses that body is validated against platform limits immediately, that media is downloaded and checked right away with refusals surfaced in the schedule preview, and the exact quote_url failure conditions. It also explains idempotency semantics precisely: same key returns the existing post, reuse with different arguments is rejected — behavior an agent cannot infer from idempotentHint alone.

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?

Purpose is front-loaded in the first sentence and no sentence is filler — each clause carries behavior. However, the quote_url sentence is a long overloaded chain ("which stays visible above X's quote card and counts toward the post's length") that is harder to parse than necessary.

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 six parameters, a nested media object, and an output schema present, the definition covers everything an agent needs that structured fields do not: draft-vs-schedule scope, immediate validation, media refusal handling, quote restrictions, and idempotent retry behavior.

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?

Although schema coverage is 100%, the description adds substantial semantics the schema lacks: quote_url is refused on cross-platform targets or where a quote cannot coexist with media, and on X it becomes an appended link that counts toward length. It also clarifies series_key's filing behavior and the exact idempotency_key retry contract.

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 opens with a specific verb+resource: "Create a draft post targeting one or more connected accounts." It also states the scope boundary explicitly with "This saves a draft: scheduling is a separate step," which separates it from schedule_post and edit_post without the agent needing to inspect schemas.

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 clear routing context by declaring that this creates a draft and that scheduling is a separate step, which steers the agent toward schedule_post for publishing. It does not explicitly address when to prefer edit_post or create_series over this tool, so the alternative mapping is only partially covered.

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