Skip to main content
Glama

Create post

create_post

Create a new social media post. Can be saved as a draft or scheduled for a specific time. Supports platform-specific content overrides, media attachments, labels, and thread format. IMPORTANT: YouTube and TikTok REQUIRE video — do not include them when posting images only. Instagram defaults to feed_photo — set postTypeOverrides for video content (reel, feed_video). Use this when the user wants to draft or schedule one new post (do not publish immediately unless asked).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
labelsNoArray of label IDs to tag the post with.
statusNoPost status. "draft" (default) or "scheduled".
contentNoThe post text content. Optional — defaults to empty for media-only posts.
channelsYesArray of channels to post to. Get channel IDs from list_channels.
timezoneNoTimezone for scheduling (e.g. "America/New_York"). Defaults to UTC.
postFormatNoPost format. "post" (default), "video", "reel", "story", "carousel", or "thread" for multi-part threads.
scheduledAtNoISO 8601 datetime for scheduling (e.g. 2025-01-15T10:00:00Z). Required when status is scheduled.
threadPartsNoThread parts array. Required when postFormat is thread (min 2 parts).
mediaFileIdsNoArray of media file IDs to attach. Upload media first with upload_media.
platformContentNoPer-platform content overrides, e.g. { "x": "Short tweet", "linkedin": "Longer LinkedIn post" }.
requestApprovalNoOptional (default false). Set true to hold a scheduled post for team approval (approvalStatus becomes 'pending'). Forced on server-side for API keys of roles without post:publish (contributors), regardless of this flag.
platformSpecificNoPlatform-specific settings, e.g. { "youtube": { "title": "…", "privacyStatus": "public" } }. Reddit, Discord, Tumblr and Snapchat nest their options under the BulkPublish channel id, e.g. { "reddit": { "12": { "subreddit": "webdev" } } }. Telegram takes no options.
postTypeOverridesNoPer-platform post type override. E.g. { "instagram": "reel", "youtube": "short" }.
linkTrackingOverrideNoOptional per-post override for link tracking (bulkpubli.sh). true forces links in this post to be shortened and their clicks counted, false forces them to publish as written, and null/omitted (the default) inherits the organization's Link Tracking setting. Shortening happens at publish time, per channel, so two accounts on the same platform get distinct codes; it is skipped for a channel when the rewrite would push the post past that platform's character limit (a short URL is 28 characters and can be longer than the link it replaces).

TDQS

A4.4/5.0
Behavior4/5

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

Annotations only carry readOnlyHint=false and destructiveHint=false, so the description carries most of the behavioral burden. It goes well beyond the baseline by explaining draft/schedule behavior, platform-specific content overrides, and critical constraints: YouTube and TikTok require video, and Instagram defaults to feed_photo. These are non-obvious traits an agent must know before calling 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.

Conciseness5/5

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

The description is compact yet information-dense, with the core action first, then capabilities, then two 'IMPORTANT' caveats, and a final use-case sentence. Every sentence earns its place, and the critical constraints are highlighted rather than buried.

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 tool's complexity (14 parameters, nested objects, no output schema), the description provides the essential selection criteria and the most dangerous platform defaults. It does not enumerate every platform-specific quirk, but those are already richly documented in the input schema, so the description is highly adequate without being exhaustive.

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. The description adds meaningful parameter-level guidance beyond the schema, particularly 'Instagram defaults to feed_photo — set postTypeOverrides for video content (reel, feed_video)' and the mapping of capabilities to labels, media attachments, and thread format. This elevates it above the baseline but it still doesn't detail every parameter, which the schema already handles.

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 pair ('Create a new social media post') and immediately narrows the scope to drafting or scheduling a single new post. The closing sentence ('do not publish immediately unless asked') differentiates it from publish_post, making the tool's purpose unambiguous even among many siblings.

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?

The description explicitly states when to use the tool: 'Use this when the user wants to draft or schedule one new post.' It also warns against immediate publishing. However, it never names alternatives like publish_post, compose_post, or bulk_posts, so the when-not guidance relies on inference rather than explicit sibling routing.

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.

TDQS

A3.8/5.0
Disambiguation3/5

Many tools occupy adjacent spaces, especially the interactive view_* tools versus their get_/list_ counterparts (view_posts/list_posts, view_analytics/get_analytics) and the multiple upload paths (upload_media, create_media_upload, multipart flow). Detailed 'Use this when' guidance helps, but an agent could still misselect between compose_post and create_post or between bulk_posts and the individual delete/retry/update operations.

Naming Consistency5/5

Tool names follow a highly consistent verb_noun pattern throughout: create/get/update/delete/list for each resource (posts, media, labels, channel sets, RSS feeds, schedules), plus publish/approve/reject/retry/upload/view. No style mixing or inconsistent casing.

Tool Count1/5

51 tools is an extremely large surface, crossing the calibration's 50+ extreme threshold. While the platform covers many subdomains, this volume is likely to overwhelm agents and makes the toolkit unwieldy for an MCP server.

Completeness4/5

The toolkit provides broad lifecycle coverage: CRUD for posts, media, labels, channel sets, RSS feeds, and schedules, plus publishing, approvals, retries, bulk operations, analytics, quota, channel health, and media upload variants. Minor gaps exist, such as no get_channel single-resource getter and no way to update media labels directly, but agents can work around these.

Resources