Skip to main content
Glama

Write and schedule a post

posts_create
Destructive

PUBLISHES CONTENT: puts a post you wrote on the rail for one connected account (connections_list), at a time, in the account's next free queue slot, or now. Read platforms_list first for the platform's limits and settings schema. Free plan: 10 posts a day, and X only once a day without links, because X bills per post (402 free_daily_cap / free_x_daily_cap / free_x_link carry the reset time, a one-line pitch and a checkout URL to hand the human). Needs the publish scope.

Input Schema

NameRequiredDescriptionDefault
textYesThe post text.
audioNoInstagram Reels only (exactly one video): a platform sound Instagram attaches at publish, by id from instagram_audio_search. Needs the Instagram account connected through Facebook Login; otherwise a 409 carries the connect link.
queueNoInstead of scheduledAt: the account's next free queue slot.
titleNoThe title; YouTube requires one.
settingsNoPer-platform settings; the schema is platforms_list[].settingsSchema (TikTok privacyLevel, Reddit subreddit, YouTube privacyStatus, tags, defaultLanguage).
mediaKeysNoMedia already in the account (assets_upload returns keys).
inspirationNoWhat the post was made from: {kind: format-card|topical-story|reference-post|brand, id, url?, mode?: clone|format|inspiration, memberId?}. For a copy of a reference, kind reference-post with the member id from references_list.
scheduledAtNoISO time it goes out. Omit for now.
connectionIdYesThe account to post as (connections_list).
firstCommentNoPosted as the post's own first reply the moment it is live. LinkedIn (1250), X (280), Bluesky (300).
idempotencyKeyNoAny string unique to this one intended thing (a UUID you keep). A retry with the same key answers what the first call made, with replayed: true, and makes nothing new. Derive it from the thing, not the attempt, so every agent and every restarted run that means the same one sends the same key.

Output Schema

NameRequiredDescriptionDefault
idYes
urlYes
errorNo
statusYes
handoffNoteNo
scheduledAtNo
publishedLocationNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / settings / description
      Previous value: -"Per-platform settings; the schema is platforms_list[].settingsSchema (TikTok privacyLevel, Reddit subreddit, YouTube privacyStatus)."New value: +"Per-platform settings; the schema is platforms_list[].settingsSchema (TikTok privacyLevel, Reddit subreddit, YouTube privacyStatus, tags, defaultLanguage)."
  2. Changed1 schema field changed
    • addedInput schema / properties / idempotencyKey
      Added value: +{
      +  "description": "Any string unique to this one intended thing (a UUID you keep). A retry with the same key answers what the first call made, with replayed: true, and makes nothing new. Derive it from the thing, not the attempt, so every agent and every restarted run that means the same one sends the same key.",
      +  "type": "string"
      +}
  3. Changed2 schema fields changed
    • addedInput schema / properties / audio
      Added value: +{
      +  "additionalProperties": false,
      +  "description": "Instagram Reels only (exactly one video): a platform sound Instagram attaches at publish, by id from instagram_audio_search. Needs the Instagram account connected through Facebook Login; otherwise a 409 carries the connect link.",
      +  "properties": {
      +    "audioId": {
      +      "description": "The sound's id.",
      +      "type": "string"
      +    },
      +    "audioVolume": {
      +      "description": "The sound's level, default 100.",
      +      "maximum": 100,
      +      "minimum": 1,
      +      "type": "integer"
      +    },
      +    "videoVolume": {
      +      "description": "The video's own soundtrack under it, default 100.",
      +      "maximum": 100,
      +      "minimum": 1,
      +      "type": "integer"
      +    }
      +  },
      +  "required": [
      +    "audioId"
      +  ],
      +  "type": "object"
      +}
    • addedInput schema / properties / inspiration
      Added value: +{
      +  "description": "What the post was made from: {kind: format-card|topical-story|reference-post|brand, id, url?, mode?: clone|format|inspiration, memberId?}. For a copy of a reference, kind reference-post with the member id from references_list.",
      +  "type": "object"
      +}
  4. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "additionalProperties": true,
      +  "properties": {
      +    "error": {
      +      "type": [
      +        "string",
      +        "null"
      +      ]
      +    },
      +    "handoffNote": {
      +      "type": "string"
      +    },
      +    "id": {
      +      "type": "string"
      +    },
      +    "publishedLocation": {
      +      "type": [
      +        "string",
      +        "null"
      +      ]
      +    },
      +    "scheduledAt": {
      +      "type": "string"
      +    },
      +    "status": {
      +      "type": "string"
      +    },
      +    "url": {
      +      "type": "string"
      +    }
      +  },
      +  "required": [
      +    "id",
      +    "status",
      +    "url"
      +  ],
      +  "type": "object"
      +}
  5. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only say this is a non-read-only, open-world, destructive write; the description goes much further. It discloses free-plan caps, per-post billing on X, the specific 402 codes (free_daily_cap / free_x_daily_cap / free_x_link) with their reset time and checkout URL, and the 409 connect link for Instagram audio — exactly the failure behavior an agent must handle.

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 with the action in caps, then prerequisites, then limits, then error handling — a sensible order. It is extremely dense with nested parentheticals, which slows parsing, but nearly every clause carries operational information rather than filler.

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 an 11-parameter, nested-object, open-world mutation with an output schema, this covers what the description must: auth scope, platform prerequisites, plan quotas, and the error codes with recovery payloads. Return values are left to the output schema, appropriately.

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, but the description adds cross-parameter meaning: queue applies instead of scheduledAt, and scheduling is relative to the account's next free slot. It reinforces dependencies (connectionId comes from connections_list, settings schema from platforms_list) without restating the field docs.

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?

"PUBLISHES CONTENT: puts a post you wrote on the rail for one connected account" names the verb, the resource, and the scope (one account per call) up front. It also clarifies the timing modes (next free queue slot, or now), which separates it from read-side siblings like posts_list/posts_get.

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 real prerequisites: read platforms_list first for limits and settings schema, and the publish scope must be granted. It also states plan-level exclusions (10 posts/day, X once a day without links) and tells the agent to omit scheduledAt for immediate posting. The one gap is that posts_publish exists as a sibling and the description never says how 'or now' here differs from that tool, leaving a routing ambiguity.

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.