PlanVortex vs Posterly

A side-by-side look at the PlanVortex and Posterly MCP servers: transport, auth, tools, quality signals, and the config to install either one in Claude, Cursor, Windsurf or VS Code.

PlanVortex logoPlanVortexSocial Media · Local subprocess (stdio)Schedule posts, read comments and answer messages across eleven social networks.61GoodAuth: not declaredPosterly logoPosterlySocial Media · Local subprocess (stdio)Validate, schedule, publish, and analyze social content across 18 platforms with posterly.63GoodAuth: not declared

Verdict: choose PlanVortex for social media work as a local process; choose Posterly for social media as a local process. You can also run both side by side in one mcpServers block.

Which MCP server should you choose?

PlanVortex logoChoose PlanVortex when

  • You need dedicated capabilities in the Social Media domain.
  • You prefer a local stdio subprocess transport.
  • You have the keys it needs: PLANVORTEX_CLIENT_ID, PLANVORTEX_CLIENT_SECRET, PLANVORTEX_ORGANIZATION_ID, PLANVORTEX_MCP_ALLOW_AI, PLANVORTEX_MCP_READ_ONLY, PLANVORTEX_MCP_AUTH_TOKEN, PLANVORTEX_MCP_UPLOAD_DIRS.
  • You want tools like list_organizations, list_accounts, get_plan_use.
Explore PlanVortex

Posterly logoChoose Posterly when

  • You need dedicated capabilities in the Social Media domain.
  • You prefer a local stdio subprocess transport.
  • You have the keys it needs: POSTERLY_API_KEY.
  • You want tools like get_agent_signup_info, start_signup, get_signup_session.
Explore Posterly

Feature & specification comparison

Rows where the two servers differ are marked.

SpecPlanVortex logoPlanVortexPosterly logoPosterly
CategorySocial MediaSocial Media
Quality signal61/100 · Good63/100 · Good
Install commandConfirmedConfirmed
TransportLocal subprocess (stdio)Local subprocess (stdio)
AuthNot declaredNot declared
PricingNot declaredNot declared
Required env varsPLANVORTEX_CLIENT_IDPLANVORTEX_CLIENT_SECRETPLANVORTEX_ORGANIZATION_IDPLANVORTEX_MCP_ALLOW_AIPLANVORTEX_MCP_READ_ONLYPLANVORTEX_MCP_AUTH_TOKENPLANVORTEX_MCP_UPLOAD_DIRSPOSTERLY_API_KEY
Verified ownerCommunity listingCommunity listing
GitHub stars00
Directory activity 1 views 0 installs 0 upvotes 1 views 0 installs 0 upvotes
Tools3167

Tools & capabilities

PlanVortex tools 31

  • list_organizationsList the PlanVortex organizations this connection can reach, with their ids. Call this first when a tool says id_organization is required, or when the user names an organization you do not have an id for.
  • list_accountsThe social accounts connected to an organization: network, name, follower count and whether the connection is broken. An account with error_code other than 0 cannot publish until a person reconnects it, and that is usually the answer to 'why did this post not go out'. On LinkedIn, personal_profile marks the person's own profile, as opposed to the pages they manage.
  • get_plan_useWhat the organization's plan allows and what it has already used: accounts, storage and integrations. Check this before promising the user a connected account — a plan limit is not a transient error and retrying never fixes it. PUBLICATIONS ARE UNLIMITED on every plan: the count is reported for context and has no ceiling, so never refuse to schedule posts over it. What can stop a batch is rate — a per-hour cap per account and a daily cap per network, both in get_social_limits — and that one IS transient: waiting fixes it.
  • get_unread_countsHow many comments and private messages are waiting, in one call. This is the 'what do I have today?' tool: start here, then use list_comments or list_conversations to see what they are.
  • list_publicationsPosts of an organization, newest first, as a short projection: id, network, state, date and the first words of the text. States are draft, ready (scheduled), publishing, sended (published) and withErrors. Use get_publication for the full record of one, including why it failed.
  • get_publicationThe full record of one post, including publication_errors — the list of reasons it did not go out. This is the tool to call when the user asks why a post failed.
  • list_destinationsThe places INSIDE a connected account a post can be sent to: on Pinterest, the boards. Every Pinterest post needs one of these ids as destination_id in create_publication. Most networks have none — the account itself is where the post goes — and there this answers that it does not apply. Pass id_destination to get one board's sections. A SECRET board is seen by nobody else, so say so if the user picks one. Set refresh only for a board created a moment ago.
  • create_publicationPublish now or schedule a post on ONE connected account. Pass state 'ready' with a future publish_date to schedule, or 'draft' to leave it for a person to review. Media has to be uploaded first with upload_media; pass the returned ids in files. The text is validated against the network's limits before anything is sent. On Pinterest a pin needs things no other network asks for: a board (destination_id, from list_destinations), at least one image or video — a pin is never text alone — and, if it should lead somewhere, the URL in link. On TikTok the user has to choose who can see the post (visibility), whether people can comment, Duet or Stitch (interactions) and whether it is commercial content; nothing may be preselected. Call this without them and the answer lists what that account allows, so you can ask. On YouTube, ask whether the video is made for kids. An Instagram video can come back in state publishing while the network processes it: that is not a failure, PlanVortex finishes it by itself within minutes, and creating it again would publish it twice. Always show the user what you are about to publish and let them confirm it: this posts publicly under their brand.
  • update_publicationChange the text, media or scheduled date of a post that has NOT gone out yet (state draft or ready). A published post cannot be edited through PlanVortex; if you try, the error will say so. A Pinterest pin saved without a board (error 987) is fixed here by passing destination_id. On TikTok and YouTube the visibility and the other settings the user chose can be changed here too.
  • retry_publicationAsk PlanVortex to try a failed post again (state withErrors only: a post in state publishing has not failed, it is still on its way). Read get_publication first: if it failed because the text is too long or the account is disconnected, retrying changes nothing until that is fixed. On Instagram, error 999 (the network ran out of time) is worth retrying; 998 (it rejected the file) is not, until the file changes.
  • get_planner_templatesWhat an AI plan can be generated FROM, with the credits each template costs. Five of them: standard (a theme prompt, images generated by the model), from_images (the user's own photos, each with a description), from_text (an article by URL or pasted), from_catalog (products read live from a connected shop) and campaign (a countdown to a date, with a narrative arc). Read this before proposing a plan: the costs and the fields are prices, and they are not to be guessed or remembered. The ones that do not generate images cost a fraction — a week of 7 posts with a picture each is 519 credits on standard and 48 on from_images. Creating plans is off unless the server was started with PLANVORTEX_MCP_ALLOW_AI=1, because generating one spends AI credits. If create_ai_plan is not in your tool list, that is why: tell the user to add it to the env block of their MCP configuration.
  • list_store_productsThe products of a shop connected to the organization (a WooCommerce store), to choose the ones a from_catalog AI plan writes about. Without id_integration it lists the organization's connected shops, with the id to pass back. With it, one page of that shop's products, read live: search by text rather than walking the whole catalogue, and pass next_cursor back exactly as given. Out-of-stock products come marked and cannot be chosen. A product without a price has none to show, and a price is text to repeat as is, never a number to do maths with. Connecting a shop needs a person in the PlanVortex panel.
  • +19 more on the listing page

Posterly tools 67

  • get_agent_signup_infoExplain how to use posterly MCP for agent-led signup before an API key exists, including the safe human-in-the-browser boundaries.
  • start_signupStart the public posterly paid signup flow for a user before posterly API access exists. Returns a signup poll URL, a browser Checkout fallback URL, and, when enabled, a prepaid PaymentIntent the agent can pay with a Link Agent Wallet virtual card (credential_type: card). The user still sets a password and approves social OAuth in the browser. Never ask for card numbers, a posterly password, or social passwords in chat.
  • get_signup_sessionPoll a public posterly signup session created by start_signup. Use this to narrate payment (Link virtual card or browser Checkout), password setup, and agent access status before a posterly API key is installed. Keep updates user-facing; do not narrate raw HTTP, curl, or API plumbing.
  • whoamiWho you are and how posterly is connected. view=identity (default): the authenticated user, API key scopes, workspaces, and onboarding next step. ALWAYS call this at the start of a session; if onboarding.completed is false, walk the remaining onboarding steps IN THIS conversation (about you, connect, brand voice, first post) and do not send the user to /onboarding-v2 or the dashboard composer wizard. view=status: MCP server version, latest npm version, endpoint and API key health, and update guidance; works before POSTERLY_API_KEY is configured.
  • list_accountsConnected social accounts and what posterly has learned about them. view=accounts (default): connected accounts, optionally one workspace_id or one account_id; Instagram rows identify direct-login versus Meta-linked connections and whether native media tags/collaborators are available, so check this before Instagram user_tags or collaborators. view=learned_voice (account_id): the voice learned from the account's real published captions (summary, traits, style guidelines, habits); read-only, never overwrites the saved brand profile. view=performance_profile (account_id): 90-day coaching stats, engagement-rate trend, and summary (Pro plan or higher; platforms without per-post analytics never get one). view=connect_session (session_id): poll a session from create_connect_session and keep the user updated in plain language; stop when status is connected, failed, cancelled, or expired.
  • disconnect_accountDisconnect a connected social account from posterly. DESTRUCTIVE and IRREVERSIBLE: removes the account connection, emits account.disconnected webhooks, and may transfer Instagram scheduled posts to a replacement account. REQUIRED BEFORE CALLING: Call `list_accounts` first, show the user the exact platform, username, account ID, and workspace that will be disconnected, then get explicit confirmation. Pass confirm=true only after that confirmation.
  • connect_accountConnect a credential-based social account (telegram, bluesky, discord, wordpress, devto, hashnode, lemmy) directly, without a browser session. Call list_platforms with view=connect_link first to discover the exact credential fields the platform needs. Prefer scoped secrets: app passwords (Bluesky, WordPress), bot tokens (Telegram), webhook URLs (Discord), and API tokens (Dev.to, Hashnode) over primary passwords. Warn the user that any credential they share passes through this conversation. For OAuth platforms (Instagram, X, LinkedIn, ...) use create_connect_session instead.
  • create_connect_sessionCreate a short-lived posterly dashboard handoff session for connecting a social account. Send the secure connection URL to the user, then poll list_accounts with view=connect_session to narrate progress. Do not ask for social media passwords or OAuth codes; posterly handles those browser steps.
  • create_api_keyCreate a new posterly API key for the authenticated user. SECRET-CREATING WRITE: only use after explicit user confirmation. The new key can only request scopes already present on the calling dashboard-created API key; OAuth and managed assistant tokens cannot mint keys. Team management (members:read, members:write) and client portal sign-in link permissions are never copied or granted here: a person turns them on in /dashboard/api.
  • delete_api_keyRevoke a posterly API key owned by the authenticated user. DESTRUCTIVE: call whoami or use a known key ID, show the user the exact key ID/prefix/name if available, and get explicit confirmation before calling. Cannot revoke the key currently authenticating this request, OAuth-issued keys, or managed assistant keys.
  • list_workspace_membersList the people in a workspace: members (with role, status, brand access and API access) and pending invites, plus seats in use. API access says whether a teammate can use this workspace's API plan from their own keys and AI apps; owners and admins also see each member's key count, connected AI apps and last use. Needs an API key with the Manage team permission. Any workspace member can list; brand-limited teammates only see brand ids they can access.
  • manage_workspace_memberInvite, update, or remove a workspace colleague. This SENDS EMAILS and CHANGES WHO CAN ACCESS the workspace. Needs an API key with the Manage team permission, and the caller must be a workspace owner or admin. ALWAYS preview first: call without confirm, show the preview to the user, and only call again with confirm: true plus the returned preview_id after the user explicitly approves. action=invite: email and role required (publisher, editor or viewer), optional brand_ids and resend; always sends a pending invite email, never adds anyone instantly. action=update: member_id or invite_id (from list_workspace_members) plus role and/or brand_ids; or member_id plus api_access (true or false, on its own) to turn API and AI app access on or off for that teammate, which lets them use the workspace API plan from their own keys and AI apps (off by default; you cannot change your own; only the owner can change it for an admin; turning it off stops their keys, AI app connections and webhooks for this workspace). action=remove: member_id (removes the teammate and revokes their API keys for this workspace) or invite_id (cancels a pending invite). Admin seats can only be granted in the posterly dashboard. The workspace owner is emailed about every change.
  • +55 more on the listing page

Ready-to-paste client configs

Paste either block (or both) into your client config, e.g. claude_desktop_config.json or ~/.cursor/mcp.json. We only show a config when the install command is confirmed.

PlanVortex

mcpServers (Claude Desktop / Cursor)
{
  "mcpServers": {
    "planvortex": {
      "command": "npx",
      "args": [
        "-y",
        "planvortex-mcp"
      ],
      "env": {
        "PLANVORTEX_CLIENT_ID": "YOUR_PLANVORTEX_CLIENT_ID_HERE",
        "PLANVORTEX_CLIENT_SECRET": "YOUR_PLANVORTEX_CLIENT_SECRET_HERE",
        "PLANVORTEX_ORGANIZATION_ID": "YOUR_PLANVORTEX_ORGANIZATION_ID_HERE",
        "PLANVORTEX_MCP_ALLOW_AI": "YOUR_PLANVORTEX_MCP_ALLOW_AI_HERE",
        "PLANVORTEX_MCP_READ_ONLY": "YOUR_PLANVORTEX_MCP_READ_ONLY_HERE",
        "PLANVORTEX_MCP_AUTH_TOKEN": "YOUR_PLANVORTEX_MCP_AUTH_TOKEN_HERE",
        "PLANVORTEX_MCP_UPLOAD_DIRS": "YOUR_PLANVORTEX_MCP_UPLOAD_DIRS_HERE"
      }
    }
  }
}

Posterly

mcpServers (Claude Desktop / Cursor)
{
  "mcpServers": {
    "posterly-2": {
      "command": "npx",
      "args": [
        "-y",
        "posterly-mcp-server@latest"
      ],
      "env": {
        "POSTERLY_API_KEY": "YOUR_POSTERLY_API_KEY_HERE"
      }
    }
  }
}

Frequently asked questions

PlanVortex is categorized under Social Media and uses a local stdio subprocess. Posterly belongs to Social Media and uses a local stdio subprocess. Pick PlanVortex for social media work and Posterly for social media.

Copy the mcpServers block from the config section on this page into your client's config (for example claude_desktop_config.json or ~/.cursor/mcp.json), then fully restart the client.

PlanVortex has no declared pricing — check the project's own site. Posterly has no declared pricing — check the project's own site. If a server needs environment variables such as API keys, define them under the env key in your client's MCP config.

Yes. MCP clients support multiple servers: add planvortex and posterly-2 as separate keys in the same mcpServers object, and your assistant will call tools from either one.

On AllMCPs, PlanVortex has a quality signal of 61/100 (Good) with 1 views, 0 installs and 0 GitHub stars. Posterly has 63/100 (Good) with 1 views, 0 installs and 0 GitHub stars.