Posthive

create_post

Create a post in Posthive. BY DEFAULT posts are saved as DRAFTS and require manual approval in the Posthive review queue before anything is published. Nothing is published automatically unless schedule_directly is explicitly set to true with a future scheduled_time. Use list_accounts to get valid account IDs before calling this tool. Each platform has its own character limit for both the post text and the first_comment — the request is rejected with a 400 if either exceeds it for any selected account: Bluesky 300, Threads/Mastodon/Pinterest 500, Instagram/TikTok 2200, Discord 2000, LinkedIn 3000, Telegram/Tumblr 4096, YouTube 5000, Nostr/Lemmy 10000, Twitter/X 25000, Facebook 63206. Check the content and first_comment length against the shortest limit among the selected platforms before calling, and warn the user if a caption (especially a long hashtag block) would be rejected.

Input Schema

Name	Required	Description
`content`	Yes	The post text content.
`dry_run`	No	Full pipeline test without real API calls.
`media_type`	No	Instagram media type. 'post' = feed image/carousel, 'reel' = video reel, 'story' = story. Only relevant for Instagram accounts.
`media_urls`	No	Array of already-uploaded media URLs (images or video). Upload via POST /api/v1/upload first to get URLs.
`account_ids`	Yes	Array of account IDs. Use list_accounts to get IDs.
`per_account`	No	Per-account content overrides. Keys are account IDs.
`youtube_type`	No	YouTube video type. 'short' = YouTube Short (vertical, ≤60s), 'video' = standard upload. Only relevant for YouTube accounts.
`first_comment`	No	Optional first comment to fire after the post goes live.
`repeat_ends_at`	No	ISO 8601 datetime after which no more repeat occurrences are created. Omit for indefinite repeating.
`scheduled_time`	No	ISO 8601 datetime for publish time. Required when schedule_directly is true.
`repeat_interval`	No	Repeat this post automatically after each successful publish. Spawns the next occurrence at the same time.
`schedule_directly`	No	When true, post is scheduled directly and publishes at scheduled_time without manual approval. Requires scheduled_time. Defaults to false (saves as draft).

Output Schema

Name	Required	Description	Default
`id`	No
`_note`	No
`draft`	No
`status`	No
`targets`	No
`scheduledFor`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 18, 2026

addedInput schema / properties / repeat_ends_at

Added value: +{
+  "description": "ISO 8601 datetime after which no more repeat occurrences are created. Omit for indefinite repeating.",
+  "type": "string"
+}

addedInput schema / properties / repeat_interval

Added value: +{
+  "description": "Repeat this post automatically after each successful publish. Spawns the next occurrence at the same time.",
+  "enum": [
+    "daily",
+    "weekly",
+    "monthly"
+  ],
+  "type": "string"
+}

First observedOct 12, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare this is not read-only, not destructive, and interacts with external platforms. The description adds valuable behavioral context beyond annotations: the default draft/approval flow, the exact condition for automatic publishing (schedule_directly + future scheduled_time), and that requests are rejected with a 400 when character limits are exceeded for any selected account.

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?

The description is front-loaded with the most important behavioral facts (default draft, approval, schedule_directly condition) before moving to setup guidance and detailed character limits. The long character-limit list is useful but slightly bulky, though every sentence provides actionable information for correctly invoking the tool.

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?

Given the complexity (12 parameters, nested objects, output schema present), the description covers the critical operational details: default draft behavior, how to publish directly, account ID lookup via list_accounts, and rejection conditions for content length. It does not discuss every optional parameter (e.g., media_type, repeat_interval), but those are fully documented in the schema and output schema exists.

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 description coverage is 100%, so the baseline is 3, but the description adds meaningful semantics for content and first_comment by enumerating per-platform character limits (e.g., Bluesky 300, Threads/Mastodon/Pinterest 500, etc.) and advising the agent to check against the shortest limit among selected platforms before calling.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Create a post in Posthive.' It clarifies the default draft/approval workflow and the schedule_directly alternative, but does not explicitly name or differentiate from sibling tools like create_from_template or duplicate_post.

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?

Gives clear context: posts default to drafts requiring manual approval, and nothing publishes automatically unless schedule_directly is true with a future scheduled_time. It also directs the agent to call list_accounts first and warns about platform-specific character limits, but does not state when to avoid this tool or use an alternative.

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

All Posthive 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?