Use SuprPost from your AI assistant

Connect Claude, ChatGPT, Cursor or any app that speaks the Model Context Protocol (MCP), then plan, draft, schedule and fix posts by just asking. Everything it does goes through the same rules as the SuprPost app — your workspaces, accounts, team roles and plan.

Connect

Point any MCP-compatible AI app at this server URL, then sign in and choose what it may do.

https://app.suprpo.st/api/mcp

1In Claude, go to Settings → Connectors.
2Select Add custom connector.
3Paste the server URL above and confirm.
4Click Connect, then sign in to SuprPost and approve the access you want to give.

You stay in control

Assistants save drafts by default, so you review what they wrote in SuprPost before anything goes out. When you connect an app you choose exactly what it may do, and you can disconnect it at any time from AI Agents & API in SuprPost — access stops immediately. Posts an assistant creates are marked with the app's name.

View your workspaces and connected accounts
View your scheduled, draft, and published posts
Create, reschedule, and delete posts on your behalfIncludes scheduling — a scheduled post publishes on its own at the chosen time.
Publish posts immediately to your connected accountsLeave this off to keep the final say: the app can still draft and schedule, but can't publish anything right away.

Things to ask

“Draft next week's posts for our LinkedIn and Instagram around any holidays — save them as drafts.”
“Turn this blog post into a post for each of my accounts, shorter for X and Bluesky.”
“What's scheduled this week? Move Tuesday's post to Thursday at 10am.”
“Why did yesterday's LinkedIn post fail? Retry it if it's safe.”
“Which days in the last month did we not post anything?”

Some assistants also offer SuprPost's ready-made prompts: Plan a week of posts, Repurpose content per platform and Recover failed posts.

Tools

What your assistant can call. You don't need these names — just ask in plain words — but they help when you're building your own agent.

Know the workspace

Workspaces, connected accounts, and the options some platforms need.

list_workspacesRead-only: List the workspaces (brands or clients) this user can access, with each one's timezone and the user's role. Scheduled times are interpreted in the workspace's timezone. `isDefault` marks the workspace tools use when no workspaceId is passed.
list_social_accountsRead-only: List the connected social accounts in a workspace — the ids create_post targets. An account with `canPublish: false` can't publish until the user reconnects it in SuprPost — tell them, using its `note`.
choose_accountsRead-only: Show the user a checklist of their connected accounts to tick, when they haven't said exactly which accounts to post to (e.g. "post this on Instagram" with several Instagram accounts connected). If their message carries attachments, call attach_chat_files BEFORE this: their answer arrives as a new turn, where the attachments are no longer available. Pass the platforms they named to narrow the list, and any accounts they did name as preselectedAccountIds. When the post has media, pass mediaCount: the checklist then says which platforms take fewer items (X takes 4), so the user knows a choice of media follows in check_post's review card. Then stop and wait: their choice arrives as their next message, naming each account and its id. Don't guess or choose for them.
list_pinterest_boardsRead-only: List a connected Pinterest account's boards. Every Pinterest account a post targets needs a board — pass it in create_post's pinterest.boardIds.
search_threads_locationsRead-only: Search for a place to tag on a Threads post. Only works for Threads accounts with canTagLocation. Pass the chosen id as create_post's threads.locationId, and its name as threads.locationName so SuprPost can show the user which place was picked.
lookup_threads_profileRead-only: Confirm the public Threads account behind an @mention before tagging it. Only works for Threads accounts with canLookupProfiles. Exact username only (no search); only public accounts with 100+ followers resolve, so not_found doesn't mean the account doesn't exist. Tag by writing @username in the caption — nothing else is needed.

Create posts

Draft, check, schedule or publish — one post or a whole batch.

create_post: Creates exactly one post for one or more connected accounts: a draft (recommended — the user reviews it in SuprPost), scheduled, or published now. The post type comes from the media: none = text, one image, a carousel, a video, or mixed media. Use perPlatform to tailor the caption or add a first comment per platform, and perAccountMedia to give one account a subset of the media. Run check_post first, then follow its state: - "ready": where the user sees SuprPost's review card, they save from it. Call create_post with the same input and its reviewSessionId when they ask you in the chat to save it, or when your app shows no card. - "review_required": do NOT call create_post. The SuprPost review card shown to the user owns creating this post; when the user saves there, the post already exists. - "blocked": fix the problems and run check_post again. A result with terminal: true means the post exists — calling create_post again would make a duplicate. Confirm with the user before using mode "now".
check_postRead-only: Dry run before creating a post: validates it exactly as create_post would, then checks each destination against its platform's rules (caption length, media count, type and size). Nothing is saved. Returns a state, a reviewSessionId, and each destination's readiness, caption and issues. - "ready": every destination is valid. Where the user sees SuprPost's review card, they save from it; call create_post with the same input and the reviewSessionId when they ask you in the chat to save it, or when your app shows no card. - "review_required": some destinations need changes and SuprPost's interactive review card is shown to the user. The card now owns creating this post. STOP calling tools for this posting request and wait for the user. Do NOT call create_post, update_post, schedule_post, publish_post or any other mutation for it — when the user saves, schedules or publishes from the card, the post already exists; don't recreate it. - "blocked": the input itself is invalid (e.g. a missing Pinterest board). Fix it or ask the user, then check again. If the user wants it scheduled but gave no time, pass mode "schedule" with no scheduledAt: the review card asks them to pick the time (needsTime: true). Never invent a time. When re-checking the same post (after fixes, or because the user asked for changes in the chat), pass its reviewSessionId so it stays one post. For one post at a time: a batch goes straight to create_bulk_posts, which runs these checks on every post itself.
create_bulk_posts: Create a batch of posts in one call — the fastest way to fill a content calendar. Each post has its own caption, media and (for mode "schedule") its own scheduledAt; all share the batch's accountIds unless a post sets its own. All-or-nothing: if any post is invalid or a platform would reject it, nothing is saved and every problem is listed — so don't run check_post on each post first. Prefer mode "draft" so the user can review the batch in SuprPost. Every call creates new posts: once a batch succeeds, don't send it again (pass an idempotencyKey so a retry after a lost answer returns the same posts). Never use it for a post check_post put in review (state "review_required").
schedule_post: Schedule a new single-media post for a future time. Older, simpler form of create_post with mode "schedule" — prefer create_post. Creates a new post on every call: once it succeeds, don't call it again for the same request, and never for a post check_post put in review (state "review_required").
publish_post: Create a single-media post and publish it immediately. Older, simpler form of create_post with mode "now" — prefer create_post. Confirm with the user first. Creates and publishes a new post on every call: once it succeeds, don't call it again for the same request, and never for a post check_post put in review (state "review_required").

Manage posts

Find, edit, reschedule, publish, retry and clean up.

list_postsRead-only: List a workspace's posts, filtered by status (draft, scheduled, queued, recurring, published, failed), platform, account, or date range, newest first by default. Queued posts wait in a queue and recurring posts repeat on a rule; each of their publications is separate. Paged: pass nextOffset to continue.
list_scheduled_postsRead-only: Older name for list_posts — same inputs and results. Prefer list_posts.
get_postRead-only: Get one post in full: its content, per-platform settings, and each destination's outcome — published (with its URL), failed (with the reason), or still pending. Use it to check a publish, or to explain a failure before offering retry_failed_destination.
get_post_metricsRead-only: For a published post: each destination's current state on its platform (live, processing, deleted…) and its latest captured metrics — normalized (views, engagements, likes, comments, shares…) and the platform's own counters. Videos add how they were watched where the platform reports it: videoStarts, views3s, views10s, completions, watchTime and avgWatchTime (milliseconds), skipRate and avgPercentWatched (0–100), and a retention curve (share of plays still watching from start to end). A metric a platform doesn't report is absent, never 0; metricsNotice says why numbers are missing. Queue and recurring posts list one run per publication.
update_postDeletes data: Change a draft or scheduled post. Send only what should change — everything omitted keeps its current value (get_post shows the current values). mode defaults to the post's current state; pass mode "schedule" with scheduledAt to schedule a draft, "draft" to unschedule, or "now" to publish it (confirm with the user first). Edits that one post in place — it never creates another, so it's how to change a post that already exists (including one the user saved from the review card).
reschedule_postDeletes data: Move a scheduled post to a new time. Only works on scheduled posts; to schedule a draft use update_post or bulk_schedule_posts. Once it answers, the post is at the new time — call again only if the user asks for a different time.
cancel_scheduleDeletes data: Turn a scheduled post back into a draft, so it won't publish. Nothing is deleted. Once it succeeds the post is a draft — a repeat call fails, so check get_post instead of retrying.
duplicate_post: Copy any post — even a published or failed one — into a new draft with the same content, accounts and media. Handy for reposting or reusing a format.
delete_postDeletes data: Permanently delete a post from SuprPost. For a published post this removes SuprPost's record only: the post stays live on every platform except Threads, where the published Thread is deleted too, and SuprPost can then no longer delete it from the platforms. No MCP tool deletes live posts from the platforms; the user can do that per post from Post details in the SuprPost app (every platform except Instagram) or on the platform itself. Confirm with the user before deleting and say plainly that the live posts stay.
publish_nowDeletes data: Publish a draft or scheduled post immediately. Publishing runs in the background — check get_post for each destination's result. Confirm with the user first. Call it once per request: a destination is never posted twice, but repeating it while the post is publishing does nothing useful — follow up with get_post.
retry_failed_destination: Retry publishing one failed destination of a post (by its accountId from get_post). Destinations that already published are never re-posted. If get_post marked it mayHavePublished, check the platform with the user first — it might be live already. One retry per request: if it fails again, tell the user the new error instead of retrying in a loop.
bulk_schedule_posts: Schedule several existing drafts at once, each at its own time — e.g. after the user approves a batch from create_bulk_posts. All-or-nothing: every post must be a draft in the same workspace, and every time must be in the future. After it succeeds the posts are scheduled; a repeat call fails because they're no longer drafts — use reschedule_post to move one.

Media

Bring images and videos into the library.

attach_media_from_url: Download an image or video from a direct, public URL into the workspace's media library and return its mediaId for create_post. JPG, PNG, WebP and GIF up to 10 MB; MP4 and MOV up to 250 MB. The URL must serve the file itself — no sign-in, no HTML page, no redirect.
attach_chat_files: Add images and/or videos the user attached to this chat to the workspace's media library, returning their mediaIds in the order given. Call it in the SAME turn as the message that carries the attachments — before choose_accounts, check_post or asking the user anything — because the app hands attachments to tools only in that turn; after a reply (e.g. the account picker's) they're gone, and you must ask the user to attach them again. Then pass them to create_post as mediaIds (several = a carousel; check_post reports what each platform can't take — a photo+video mix, more items than it allows — and its review card lets the user choose which items each account gets; create_post refuses such a post). Pass the attachments themselves as `files`, up to 30 per call. JPG, PNG, WebP and GIF up to 10 MB; MP4 and MOV up to 250 MB. Each file is reported separately: the ones that were added have a mediaId, the rest an error. A file refused by the hourly upload limit says so, with retryAfterSeconds — wait that long, then call again with only the missing files; don't post without them unless the user says to. If other files fail, tell the user which before posting without them. If your app can't hand you the attachments (no download URLs), say so and ask the user to upload them in SuprPost's media library or give direct URLs — never use list_media items as stand-ins for files the user attached.
create_upload_url: Upload a file you can reach yourself (on your filesystem or in your code sandbox) without passing its bytes through the chat: returns a short-lived uploadUrl. PUT the raw file bytes to it with the given Content-Type header — e.g. curl -X PUT -H "Content-Type: image/png" --data-binary @shot.png "<uploadUrl>" — then call complete_upload with the mediaId; only then is the mediaId usable in create_post. JPG, PNG, WebP and GIF up to 10 MB; MP4 and MOV up to 250 MB. One call per file; sizeBytes must be the file's exact size: the URL is signed for it, so the PUT's Content-Length has to equal sizeBytes or storage refuses it. The URL expires 2 minutes after it's issued. Prefer this over upload_media for anything but tiny files. It can't reach files the user attached to a chat you can't read from disk — use attach_chat_files for those where the app provides them.
complete_upload: Confirm that a file was PUT to the uploadUrl from create_upload_url. Checks the stored file (type and size) and makes its mediaId ready for create_post. Safe to call again. If it says the file wasn't found, the PUT didn't land — upload it, then call this again.
upload_media: Upload an image or video by its base64-encoded content and return its mediaId for create_post — for files with no public URL. For a file the user attached to the chat, prefer attach_chat_files when it's available. Only with the file's real bytes: never write out base64 for an image you can see but can't read as a file — ask the user to upload it in SuprPost or give a URL instead. JPG, PNG, WebP and GIF up to 10 MB; MP4 and MOV up to 250 MB; base64 adds about a third to the size.
list_mediaRead-only: List the workspace's media library, newest first, so an existing image or video can be reused by its mediaId instead of uploading it again. Only for media the user asks to reuse (or picks from the list) — never as a substitute for files they attached in the chat, even if the names look similar.

Plan

The calendar, holidays, posting cadence and past captions.

get_calendarRead-only: The workspace's calendar for a date range (max 92 days): every post on each day with its local time and status, plus holidays and observances (global, regional to the workspace's timezone, and the team's own custom days). Use it to plan around key dates and spot empty days before proposing posts.
get_posting_activityRead-only: How much the workspace has been posting: posts per day over a range (max 92 days, default the last 30), totals by status, the days with nothing posted, and how many posts are queued per account. Use it to find gaps and keep a steady cadence.
search_past_captionsRead-only: Search the workspace's previously used captions (or first comments), plus the ones the team saved to reuse — newest first, one entry per distinct text. Use it to match the brand's voice, reuse hashtags and sign-offs, and avoid repeating a recent caption.

Building a plain integration instead? The same actions are available over the REST API — create an API key in SuprPost under AI Agents & API.