Skip to main content
Glama
Sign In
PlanPost MCP Server

PlanPost MCP Server

by lukBB
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

create_post

Destructive

Create and schedule social media posts across connected platforms, saving them as drafts or queuing them for a specific time with per-platform content and media.

Instructions

Create a new social media post. Saves as draft or schedules it for a specific time. X (Twitter): nothing sent to X may contain a link (URL, bare domain or t.co) — not the post, any thread segment, or a first comment (posted to X as a reply). The X API bills each link post at $0.20 vs $0.015, so the API rejects them; put a link-free version in platformContent.twitter.

Input Schema

NameRequiredDescriptionDefault
utmNoPer-post UTM tag overrides applied when attribution mode is utm. Each field can include the `{platform}` placeholder (substituted per platform at publish time). Letters, digits, `-`, `_`, `.` only. Any field omitted falls back to the user's UTM defaults configured in Settings, then to a hardcoded fallback. Example: { campaign: "summer-2026", content: "weekly-tips" }.
labelNoInternal working name shown in the PlanPost dashboard list, e.g. 'Garmin CIRQA - IG Carousel'. Never published to any platform — it just makes a campaign's drafts tellable apart. Highly recommended when creating several posts at once.
mediaNoMedia attachments shared across every platform (use upload_media first to get URLs). Override per-platform via platformMedia.
contentYesPost text content
campaignNoCampaign tag, e.g. 'garmin-cirqa-2026' (slugified automatically). Sets utm.campaign and derives a utm.content token from the format (e.g. 'ig-carousel', 'fb-static'). Group/filter/bulk-delete by this with list_campaigns, list_posts({campaign}) and delete_posts({campaign}).
postTypeNoExplicit post type (clearer than platformSettings flags, and takes precedence over them). 'reel' needs Instagram/Facebook; 'short' needs YouTube/Instagram/TikTok/Facebook; 'story' needs Instagram/Facebook; 'thread' is X/Twitter-only and requires threadSegments. Defaults to 'post', or is inferred from platformSettings flags (e.g. { instagram: { isReel: true } } → reel). NOTE: a carousel is NOT a postType — attach media with type 'carousel' or use generate_carousel/render_carousel.
scheduleNoNatural-language schedule, easier and safer than hand-building ISO: 'now', 'draft', 'today 20:30 Europe/Warsaw', 'tomorrow 07:00', 'in 2 hours', 'next week'. Takes precedence over scheduledFor. A timezone may be appended to wall-clock forms; otherwise `timezone` (or UTC) applies.
timezoneNoTimezone for scheduling (default: UTC)
scheduledForNoISO 8601 datetime to schedule the post (e.g. '2026-04-10T14:00:00Z'). Omit for draft. Prefer `schedule` for anything other than an exact instant.
connectionIdsYesArray of social connection IDs to post to. Use list_connections or list_account_groups to find IDs.
platformMediaNoPer-platform media overrides, e.g. { instagram: [<image>], twitter: [] } — instagram gets the image, twitter publishes with no media. Absent keys fall back to the shared `media` array. Empty `[]` is a meaningful 'no media on this platform'.
threadSegmentsNoOrdered tweet segments for a thread (only used when postType='thread', X/Twitter-only). 2–25 segments, each 1–280 characters.
platformContentNoPer-platform content overrides, e.g. { twitter: 'shorter version', linkedin: 'longer version' }
platformSettingsNoPer-platform settings, e.g. { instagram: { isReel: true }, youtube: { title: '...', visibility: 'public' } }. TikTok: a scheduled or published post MUST carry { tiktok: { privacyLevel } } with one of PUBLIC_TO_EVERYONE, MUTUAL_FOLLOW_FRIENDS, FOLLOWER_OF_CREATOR, SELF_ONLY (TikTok makes the user choose who can view each video; without it the API returns 400). Optional tiktok flags: disableComment, disableDuet, disableStitch (default true = off), brandedContent, yourBrand.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.0

TDQS

A3.6/5.0
Behavior4/5

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

Annotations already declare destructive/openWorld/non-idempotent, so the bar is lower, yet the description adds real behavior the schema cannot: X rejects any link at $0.20 vs $0.015 billing, and TikTok scheduling without privacyLevel returns a 400. These are non-obvious failure modes that materially change how the agent builds the call.

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 core action in the first sentence, followed by platform caveats in a compact, scannable order. It is dense but every clause carries operational information; the X billing rationale is slightly verbose for a tool description but justifies its length by explaining why the constraint exists.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 14-parameter, nested-object mutation tool with no output schema, the description omits what a successful call returns (post ID? status?) and says nothing about auth or approval workflow despite a submit_for_approval sibling. The platform-specific rules it does include are strong, but the post-call picture is incomplete.

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 description coverage is 100%, so the schema already documents all 14 parameters, including the schedule-vs-scheduledFor precedence and the platformContent shape. The description's only addition is pointing at platformContent.twitter as the place for a link-free X version, which is a small but useful semantic nudge beyond the baseline.

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?

The first sentence states a specific verb and resource (create a social media post) plus the two outcome modes (draft or scheduled). It does not explicitly route the agent away from bulk_create_posts or distinguish when to preview first, so sibling differentiation is only partially achieved via the carousel note.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use it (draft vs schedule, per-platform constraints) and points to generate_carousel/render_carousel for carousels, which is genuine alternative routing. However, it never addresses create_post versus bulk_create_posts, preview_post, or submit_for_approval, so the primary selection question is left to inference.

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

Deploy Server

Other Tools