Posthive is a social media scheduling platform that lets you manage, schedule, and publish posts across 14+ platforms, with AI agent integration via MCP (compatible with Claude, ChatGPT, Cursor, etc.) and a public REST API for full CRUD operations.
List connected accounts – Retrieve all linked social media accounts (IDs, platforms, display names).
Create posts – Compose posts as drafts or schedule them directly; supports media URLs, first comments, per-account content overrides, Instagram media types (post/reel/story), and YouTube video types (short/video).
Get post details – Fetch full details and per-platform publish status for a specific post.
List scheduled posts & drafts – View upcoming posts, filterable by status (pending, draft, done, failed) with pagination.
Approve drafts – Promote a draft to the scheduled queue by setting a future publish time.
Update posts – Edit content, scheduled time, first comment, or per-account overrides on pending or draft posts.
Duplicate posts – Clone an existing post (content, accounts, overrides) as a new draft.
Delete posts – Remove a pending or draft post from the queue.
List templates – View all saved post templates in the workspace.
Create from template – Generate a new draft or scheduled post from a saved template, with optional overrides.
Dry-run mode – Test the full publishing pipeline without making real API calls.
Self-hosting – The platform is self-hostable for full control over your deployment.
Allows scheduling and publishing posts to Bluesky, including text, images, and first comment support.
Allows scheduling and publishing messages to Discord channels.
Allows scheduling and publishing posts to Facebook, including text and images.
Allows scheduling and publishing Instagram posts, reels, stories, and carousels (up to 10 items) with image alt text.
Allows scheduling and publishing posts to Mastodon instances.
Allows scheduling and publishing Pinterest Pins with dedicated Title and Description fields (image required).
Allows scheduling and publishing messages to Telegram channels or groups.
Allows scheduling and publishing posts to Threads, including text and images.
Allows scheduling and publishing posts to Tumblr.
Allows scheduling and publishing YouTube videos (short and long-form) with dedicated Title/Description fields.
Allows scheduling and publishing YouTube Shorts with dedicated Title/Description fields.
Multi-platform posting - write once, publish to 14+ platforms simultaneously
AI agent support - connect Claude, ChatGPT, Cursor, VS Code via MCP; OAuth 2.0 + PKCE, no API key to paste
Calendar view - FullCalendar month/week/day with drag-to-reschedule
Bulk CSV scheduling - upload a spreadsheet to schedule hundreds of posts at once
Post templates - save and reuse post drafts
First comment scheduling - auto-reply immediately after the post goes live
Per-platform overrides - custom text and first comment per account
Instagram Reels & Stories - full media type support including carousels
YouTube Shorts & videos - dedicated title/description fields, custom thumbnail upload
Dry run mode - test the full pipeline without real API calls
Draft posts - save compose state, schedule later
Public REST API - full CRUD with Bearer auth (Pro/Team)
Self-hostable - Docker compose, one command, billing optional
Related MCP server: Publora MVP MCP Server
Layer | Technology |
Frontend | Next.js 16 (App Router), React 18, Tailwind CSS |
Backend | Fastify v4, TypeScript ESM, Node.js |
Database | Prisma 5 (SQLite for dev, Postgres for prod) |
Queue | BullMQ + Redis (Upstash / Railway) |
Storage | Local disk (dev) / Supabase Storage (prod) |
Resend | |
Billing | Dodo Payments (optional) |
Monitoring | Sentry |
git clone https://github.com/AstaBlackClove/posthive.git
cd posthive
cp apps/api/.env.example .env
# Fill in ENCRYPTION_KEY, JWT secrets, DATABASE_URL, REDIS_URL
docker compose up -d --buildOpen http://localhost:3000 and register. Billing is disabled by default all features unlocked.
Full setup guide → posthive.co/docs
pnpm install
cp apps/api/.env.example apps/api/.env
pnpm dev # starts API + Web + Postgres (Docker)Service | URL |
Web | |
API | |
Prisma Studio |
Environment variables & platform OAuth setup → posthive.co/docs
Connect any MCP-compatible AI agent to Posthive with a single URL no API key to generate or paste.
# Claude Code
claude mcp add --transport http posthive https://your-api/mcp
# Cursor / VS Code — add to mcp.json
{ "mcpServers": { "posthive": { "url": "https://your-api/mcp" } } }The first tool call opens your browser to sign in. Full setup per client → posthive.co/agent
10 tools available: list_accounts · create_post · get_post · list_scheduled_posts · approve_draft · update_post · duplicate_post · delete_post · list_templates · create_from_template
Questions, feature requests, bugs join the Discord:
AGPL-3.0 if you modify this project and run it as a network service, you must make your source available to users of that service.
Approve a draft post and schedule it for publishing at a specific time. Promotes a draft to the scheduled queue — it will publish at scheduled_time without further approval. Only works on posts with status 'draft'.
| Name | Required | Description | Default |
|---|---|---|---|
| post_id | Yes | Post ID of the draft to approve. | |
| scheduled_time | Yes | ISO 8601 datetime when to publish. Must be in the future. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It discloses that the tool promotes a draft to the scheduled queue and that the post will publish at scheduled_time without further approval. This covers the main behavioral traits, though it could mention that the action is irreversible or requires specific permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each earning its place. The first sentence defines the primary action, the second adds an important constraint. No redundant or filler text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description adequately explains the effect (scheduled for publishing). It could mention that the post is removed from drafts or that scheduling is irreversible, but it is mostly complete for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds little beyond the schema: it only restates that post_id must be of a draft (implied) and scheduled_time must be in the future (already in schema). No additional semantic detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Approve a draft post and schedule it for publishing') and resource ('draft post'). It distinguishes from siblings like delete_post or update_post by specifying the scheduling action, which is unique among the listed tools. No ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states a key precondition: 'Only works on posts with status draft.' This guides the agent to only use the tool when the post is in draft status. It does not explicitly mention when not to use alternatives, but the condition provides sufficient context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a draft post using a saved template as the base content. You can override the text before saving. Use list_templates to get template IDs.
| Name | Required | Description | Default |
|---|---|---|---|
| account_ids | Yes | Account IDs to post to. Use list_accounts to get IDs. | |
| template_id | Yes | Template ID from list_templates. | |
| scheduled_time | No | ISO 8601 publish time. Required when schedule_directly is true. | |
| content_override | No | Override the template text. Leave blank to use template text as-is. | |
| schedule_directly | No | When true, schedule immediately instead of saving as draft. Requires scheduled_time. | |
| first_comment_override | No | Override the template first comment. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates the action creates a draft and allows content override, but with no annotations provided, it lacks detail on side effects, idempotency, or failure modes. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, immediately states the core purpose, and contains no wasted words. Perfectly front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with no output schema, the description explains the basic workflow (draft creation, override) and links to a prerequisite. It omits the return value or status, but overall is sufficient for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover 100% of parameters, so baseline is 3. The description adds minimal extra value (e.g., referencing list_templates) but does not deeply elaborate on parameter usage beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('create') and resource ('draft post using a saved template'), and distinguishes from sibling tools like get_post and list_scheduled_posts by specifying template-based creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It mentions a prerequisite ('Use list_templates to get template IDs'), giving clear context. However, it does not explicitly indicate when not to use this tool or contrast with alternatives like duplicate_post.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | The post text content. | |
| dry_run | No | When true, runs the full pipeline 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 to post to. 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 immediately after the post goes live. | |
| scheduled_time | No | ISO 8601 datetime for when the post should go live. Required when schedule_directly is true. | |
| schedule_directly | No | When true, post is scheduled directly and will publish at scheduled_time without manual approval. Requires scheduled_time. Defaults to false (saves as draft). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It clearly states the non-obvious default of saving as drafts and requiring manual approval, and that nothing publishes automatically unless schedule_directly is true with a future scheduled_time. This is significant behavioral context that directly impacts how an agent should invoke the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, followed by the crucial default behavior and a prerequisite. Every sentence carries meaningful information with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 10 parameters and no output schema, but the description covers the most critical operational details: draft-by-default, manual approval, and the condition for direct scheduling. Combined with the thorough per-parameter schema descriptions, this is sufficient for an agent to use the tool correctly, though it does not state what the tool returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the schema fully documents all parameters. The description's mention of using list_accounts is helpful but duplicates the schema's description for account_ids. Per the rubric, baseline is 3 when schema coverage is high, and the description adds only minimal extra value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Create a post in Posthive', a specific verb+resource statement that clearly distinguishes this from sibling tools like update_post, delete_post, or list_templates. It further clarifies the key behavior of creating drafts by default, which sets expectations for what 'create' means in this context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to 'Use list_accounts to get valid account IDs before calling this tool', providing a clear prerequisite for correct usage. It does not explicitly exclude alternatives, but the context of creating a new post is clear from the tool name and sibling list, and the scheduling behavior guidance helps decide when to use schedule_directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a pending or draft post from the queue.
| Name | Required | Description | Default |
|---|---|---|---|
| post_id | Yes | The ID of the post to delete. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the action. It lacks disclosure of behavioral traits such as reversibility, authorization needs, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no unnecessary words. It is front-loaded and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description covers the basic purpose and constraints (pending/draft), it does not address error handling, expected return values, or permissions, leaving gaps for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter, so baseline 3 applies. The description provides no additional parameter semantics beyond the schema's description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (delete), resource (post), and specific qualifiers (pending or draft, from the queue). It distinguishes from siblings by restricting to non-published posts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (only for pending/draft posts) but does not explicitly state when to use or not use this tool compared to alternatives like update_post.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Clone an existing post as a new draft. Copies content, accounts, and per-account overrides.
| Name | Required | Description | Default |
|---|---|---|---|
| post_id | Yes | Post ID to duplicate. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It only mentions what is copied but omits crucial behavioral details such as whether the original post remains unchanged, what the result is (e.g., new post ID), any permissions needed, or error conditions. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is front-loaded with the core action and follows with what is copied. Very concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core functionality but omits important context such as what the tool returns (e.g., new post draft ID), whether the original post is modified, and any required permissions. Given the low complexity, it is just barely adequate but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Since schema coverage is 100%, the description does not add parameter semantics beyond the schema definition. The parameter description in the schema is already clear. Baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Clone' and clarifies the destination (new draft). It also lists the copied attributes, providing clear differentiation from sibling tools like create_post or update_post.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus siblings like create_post or update_post. It merely states what it does, leaving the agent to infer usage from the tool name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full details of a single post by ID, including per-platform publish status.
| Name | Required | Description | Default |
|---|---|---|---|
| post_id | Yes | Post ID from list_scheduled_posts or create_post. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only states purpose without disclosing behavioral traits like error handling, rate limits, or idempotency. Minimal behavioral info beyond being a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no unnecessary words. Front-loaded with action and resource, efficient and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, description adequately covers purpose and key output (per-platform status). Could specify 'full details' more explicitly, but generally sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear parameter description. Description adds no further parameter semantics beyond what schema provides, meeting baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it retrieves full details of a single post by ID, with specific mention of per-platform publish status. Distinguishes from sibling tools like list_scheduled_posts (list) and update_post (modify).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies use when needing full details of a specific post, but no explicit when-to-use or when-not-to-use compared to alternatives. Context is clear but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all connected social media accounts for this Posthive workspace. Returns account IDs, platforms, and display names. Use these IDs when creating posts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states the operation (listing) and the returned fields (IDs, platforms, names), implicitly signaling a read-only action. It does not mention side effects or pagination, but for a zero-parameter list tool, this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the primary action and resource, and includes only essential details. There is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the zero parameters, no output schema, and simple list nature, the description fully covers the tool's behavior and return value. It also connects to the broader workflow by noting the use of IDs in post creation, making it contextually complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description needs no parameter explanations. The baseline for no parameters is 4, and the description adds value by explaining the output's purpose, which is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('all connected social media accounts per Posthive workspace'), clearly distinguishing this from sibling tools that operate on posts or templates. It also states what is returned (account IDs, platforms, display names), leaving no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises using the returned account IDs when creating posts, providing clear context for when this tool should be used. It does not explicitly name alternative tools or exclusions, but no sibling tool serves the same account-listing purpose, so the guidance is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List upcoming scheduled posts and drafts in the queue.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of posts to return (default 20, max 100). | |
| status | No | Filter by post status. Omit to return all. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must carry the behavioral burden. It only says 'list ... in the queue', but does not clarify the return format, ordering, pagination beyond the limit parameter, or the fact that the status filter can include non-upcoming entries like 'done' and 'failed'. This is a minor misdirection as 'upcoming' suggests only pending/draft.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence with no wasted words. However, it could be more informative without significant added length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and full schema coverage, the description is mostly adequate but lacks context about the difference between scheduled posts and drafts, and does not mention that it can return done/failed posts as well. It also does not integrate with sibling tool context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters (limit, status) are fully described in the schema, so the description adds no extra meaning. The baseline score is 3 as schema coverage is 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'list' and the resource 'upcoming scheduled posts and drafts', which distinguishes it from sibling tools like create_post or update_post. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as list_templates or update_post. There is no mention of prerequisites, limitations, or recommended use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all saved post templates in this Posthive workspace.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It indicates a non-destructive read operation but fails to disclose output format, limits, or ordering.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words, front-loaded with verb and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no params, no output schema), the description is mostly complete. It could hint at what fields templates contain, but the current text is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist; schema coverage is trivially 100%. Baseline for zero-param tools is 4, and the description adds no parameter info because none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list) and resource (saved post templates) with workspace scope. It distinguishes from sibling tools that deal with posts rather than templates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for retrieving templates, but provides no explicit guidance on when to use it versus alternatives, nor any when-not conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update content or scheduled time of a queued or draft post. Only pending/draft posts can be updated.
| Name | Required | Description | Default |
|---|---|---|---|
| content | No | Updated post text content. | |
| post_id | Yes | The ID of the post to update. | |
| per_account | No | Updated per-account content overrides. | |
| first_comment | No | Updated first comment text. | |
| scheduled_time | No | Updated scheduled time (ISO 8601). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the status restriction but does not mention permissions, side effects, or error behavior for invalid inputs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the purpose and adding a constraint. Every sentence adds value with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters including a nested object and no output schema, the description is minimal. It covers essential constraints but lacks details on return values or handling of nested parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds context by grouping 'content or scheduled time', but the schema already describes each parameter explicitly, so no significant extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'update content or scheduled time of a queued or draft post', specifying the verb, resource, and scope. It distinguishes from siblings like create_post and delete_post.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes an important condition: 'Only pending/draft posts can be updated'. This provides clear guidance on when to use the tool, though it could explicitly mention not to use for published posts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.5.0create_postlist_accountsv0.1.1approve_draftcreate_from_templatecreate_postget_postv0.1.0create_postdelete_postduplicate_postlist_scheduled_postslist_templatesupdate_postEach tool targets a distinct resource and action: accounts, posts, templates, drafts, and scheduled items. Even create_post vs create_from_template are distinguishable by the template dependency, and the descriptions clearly state their purposes.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., list_accounts, get_post, create_post, delete_post). The one deviation, create_from_template, is still readable and fits the pattern of creating something from a template, so consistency is maintained.
With 10 tools, the server is well-scoped for a social media scheduling workflow. It covers account selection, post creation, draft management, scheduling, templating, and basic queries without unnecessary bloat.
The core draft-to-schedule workflow is covered (create, list, approve, update, delete). However, once a post is approved and scheduled, there is no way to update or cancel it, and there is no way to list published or past posts—only scheduled/drafts are listed. This creates significant workflow gaps for managing the full post lifecycle.
A free social media scheduler your AI tools can post through — LinkedIn, Bluesky, Mastodon, YouTube.
Post, schedule, and track social posts on X, Bluesky, LinkedIn, Instagram and more from AI agents.
Draft, schedule and publish social posts to nine platforms from any AI agent.
Social media scheduler for AI agents: draft posts into a human-approved queue for 15 networks.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/AstaBlackClove/posthive'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
