Octopost

Publish a saved post now

publish_draft

Publish a post that's already saved in Octopost right now: a draft, a scheduled post (it goes out now instead of at its time) or a queued post (it skips the queue). Uses the post's own text, networks, media and thread segments. Returns per-network results like create_post (or status "publishing" if slow; see get_post).

Posts waiting for human approval (pending) can't be published this way; a person approves them first. For a post that already went out and failed on some networks, use retry_failed.

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": {
      "post_id": "<post_id>"
    },
    "name": "publish_draft"
  }
}

Input Schema

Name	Required	Description	Default
`post_id`	Yes	The post ID (UUID), from list_posts or the call that saved it.
`allow_duplicate`	No	Optional. true to send text already sent to that network within 7 days (refused otherwise). See create_post.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 8, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Beyond the annotations (which only say not read-only, not idempotent, open-world, non-destructive), it discloses that the post's own text, networks, media and thread segments are reused, that results are per-network like create_post, and that a slow case returns status 'publishing' to be polled via get_post. That is substantive behavioral context the annotations do not carry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

Purpose and scope are front-loaded in the first sentence, return behavior follows, and exclusions are consolidated in a final short paragraph. No sentence is redundant; the parenthetical reminders about immediate execution and queue-skipping carry real information.

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 only two parameters and no output schema, the description does the necessary extra work: it explains the source of the published content, the return shape and the slow-path status, plus the approval and retry exclusions. An agent has everything needed to call this correctly.

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

Parameters3/5

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

Schema coverage is 100% and both parameters are already documented in the schema, including the 7-day duplicate rule for allow_duplicate. The description adds only a pointer back to create_post, so it neither compensates for gaps nor adds much meaning beyond structured data — the baseline 3 applies.

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 gives a specific verb ('Publish') plus the resource ('a post that's already saved in Octopost right now') and enumerates the three source states it covers — draft, scheduled (goes out now), and queued (skips the queue) — each with its distinct behavior. This clearly separates it from siblings like approve_queued_post, schedule_post, and retry_failed.

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?

It states both when to use it (draft, scheduled, queued posts) and when not to: pending posts awaiting human approval 'can't be published this way', and failed posts should go to retry_failed. The alternatives are named explicitly, leaving no ambiguity for the agent's routing decision.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Octopost tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?