Connect an AI Assistant to Your Social Accounts

What you are actually connecting

Three things sit between your assistant and a published post, and most setup guides describe only the middle one.

The assistant. A model plus the client you talk to: Claude, ChatGPT, Cursor, a terminal. It has no social features of its own. It can only call functions somebody hands it.

The server that exposes those functions. With MCP this is a URL the vendor runs. Your client connects, asks what the server can do, and gets back a list of named tools. That list is the entire permission surface, so it is the thing to read first. I enumerated a connected server while writing this page: eight tools, get_accounts, list_posts, create_post, upload_media, list_media, delete_post, get_analytics and create_linkedin_carousel. There is no reply tool, no comment tool and no direct-message tool in that set, so an assistant pointed at it cannot touch an inbox however you prompt it. That is not an absence from a document: it is the surface a running server advertised when asked.

The accounts. And the point of the whole arrangement is that your assistant never reaches them. The vendor already holds the platform OAuth tokens for your Instagram, LinkedIn and the rest, because you granted them in a browser when you connected the accounts. SchedPilot’s API page puts the boundary plainly: agents “only ever see your SchedPilot API key” and “never touch platform credentials”, and you can “Revoke access instantly from the dashboard”.

So the credential you are about to issue is one key standing in for every account in that vendor workspace. That is the trade, and a good one. Instead of registering developer apps on nine networks and holding nine sets of refreshing tokens, you hold one string, and one revocation ends all of it. The cost is that the key is exactly as broad as the workspace behind it.

Two questions sit upstream of this page. Whether you want something deciding on your behalf at all is the subject of agents versus rule-based automation, and which server to point at is a comparison of MCP servers for posting. This page assumes you have picked one and want it wired up without breaking anything.

Before you connect anything

Decide the blast radius first, because the key will not let you decide it afterwards.

Which accounts. Scoping happens in the vendor’s app, not in the credential. The account-listing tool on the server I called takes no arguments at all and returned the whole workspace: dozens of accounts across nine networks, personal profiles and client pages together. If your own accounts and a client’s live in one workspace, one key reaches both. Put anything you would not want a loop touching in its own workspace, with its own key.

Which actions. Read the tool list as a list of verbs and notice what is missing as carefully as what is there. On that same surface there is a create and a delete and no update, which means the only way to change a scheduled post is to remove it and make another one. Fine, once you know. Surprising at 7am, when a typo fix returns a new post id. Read the delete verb’s limits too: it cancels a scheduled post and refuses a published one with a 409, because “published posts cannot be deleted” in its own words. Your undo only works before the post goes out.

Draft-only or publish. Decide this before the key exists, and write the answer down. One of the arguments on that create call is a boolean that skips the schedule and publishes immediately. Unattended publishing is not a capability you have to build. It is a flag somebody has to not set.

Then create the narrowest key the vendor offers, and find out what narrow means there. It varies more than you would expect. SchedPilot documents optional IP allowlisting on paid plans. Vista Social’s help centre lists an MCP tool that returns the name and email of “the user whose API key is in use”, so an agent can confirm which account it is holding before it does anything, which sounds minor until the first time you connect to the wrong workspace.

And have the revoke path open in a tab. Know where the key dies, who else can kill it, and what happens to already-queued actions when it does. Test it deliberately, once, while nothing is at stake. Your vendor may also revoke on your behalf: Vista Social documents emailing the workspace owner after four rate-limit violations in an hour and deactivating the API key automatically at eleven. All of this belongs in whatever plan you have for how to automate social media, next to who owns the accounts.

Connect an AI assistant to social media, step by step

The sequence to connect an AI assistant to social media is the same whichever assistant you use. Only the location of one config file changes. Each step proves one thing, and you do not move on until it has.

1. Connect the accounts in the vendor’s app, in a browser, yourself. This is where the platform OAuth happens, with you reading the consent screen. No assistant is involved and none should be. Proves: the vendor can post to these accounts at all.

2. Issue an API key and keep it out of the conversation. Never paste it into a chat window, a ticket or a prompt file. Treat it as what it is: the credential for every account in that workspace. Proves nothing yet, which is the point of step five.

3. Add the server to your client’s MCP config. The shape barely changes between clients: a named entry, a URL, and little else.

{
  "mcpServers": {
    "social": {
      "url": "<YOUR_VENDOR_SERVER_URL>"
    }
  }
}

Two authentication styles are in circulation and some vendors document both for the same server. The key can sit inside the server URL itself, as a path segment, or travel in an Authorization: Bearer header. Postiz’s client setup page prints that same block for two different clients, shows the URL form as the default and the Bearer header as the alternative, and notes that both authenticate the same way. Prefer the header wherever your client supports it, because a URL carrying a credential gets copied into shell history, logs and screenshots, and a key in a screenshot is a key on the internet. Proves: nothing. Config files lie happily until something reads them.

4. Restart the client and confirm the tools were discovered. Do not accept a green dot. Make it show you the names and count them. A list shorter than the vendor documents usually means a wrong key, a wrong URL, or a plan that does not include the server. Proves: the handshake works and your client can see the surface.

5. List the accounts. This is the real proof of connection, and both surfaces I checked say so. Postiz’s setup page tells you to ask the agent to list your connected accounts and watch which tool it calls. The account-listing tool I enumerated describes itself the same way, instructing callers to “Always call this first to discover valid account IDs”. A list of your own account names coming back through the assistant means authentication, authorisation and transport are all working. Proves: everything up to this point, in one read-only call.

6. Copy the id and the type together, as a pair. On the server I called, numeric ids repeat across networks: the same number came back on an Instagram account, an X account, a YouTube channel and a LinkedIn company page. The create call wants both the id and the type, and LinkedIn alone returns two types, one for the personal profile and one for company pages. Record pairs, never bare numbers. Proves: you can address a specific account rather than hoping.

The first safe test

Use a throwaway account you created in order to be wrong on. Not the quiet one nobody checks. Nobody checks it until the day it posts twice.

Run the sequence in this order, and read the response at each step instead of the assistant’s summary of it.

1. List accounts. Read-only, instant, and it hands you the id and type pair you need next.
2. Upload one piece of media, then list the library. On the surface I called, media comes back with a typed id, a string like image-1649 rather than a number, and a status field. Confirm the file is processed before you attach it to anything.
3. Create exactly one post, scheduled far enough out that nothing can fire while you are still reading. Watch the timezone: the create call I enumerated defaults to UTC, so a time you typed as nine in the morning is nine UTC unless you pass your own zone. That surface has no draft argument, so a date months away is the closest thing it offers to a draft. SchedPilot documents the fuller pattern for its REST API, where an agent pushes content with a draft status and a human approves in the dashboard or through a Slack webhook before it schedules.
4. Read it back. The listing I ran returns the content, the scheduled date, the timezone, and one status per account, plus a platform post id that stays null until the network actually accepts it. Learn that shape now: it is what you read when something goes wrong.
5. Delete it, then read it back again. A deletion you have not confirmed is not a deletion.

Only now point the assistant at something real, and point it at one account rather than all of them. Keep the five calls above in your file of reusable social prompts so you can rerun the whole check in one line after you rotate a key, change plan, or connect a new network.

Rate limits and failure

The documented ceilings are generous, which is the problem. SchedPilot’s API page states that “Starter plans include 1,000 requests/hour; higher tiers include 10,000+”. Vista Social’s rate limits article gives a default of 60 requests a minute per integration and a higher cap of 180 a minute for its MCP channel, with each integration on its own budget. Neither number will stop a looping agent from publishing all day. Your own ceiling, in posts per account per day, is the one that matters, and a rate limit is not it.

Read the headers rather than counting your own calls. SchedPilot documents X-RateLimit-Remaining and X-RateLimit-Reset on every response; Vista Social documents those plus X-RateLimit-Limit, and a 429 carrying Retry-After in seconds. Vista Social’s own advice is blunter than mine: “Always trust the headers, not the docs.” It needs to be, because its help centre disagrees with itself. The article listing its MCP tools answers the rate-limit question with “We don’t have rate limits on MCP”, while its rate limits article puts the MCP channel at 180 a minute. Both are first-party and both were readable on 22 October 2026.

Partial failure is the normal failure. One call to several accounts is several publishes, and they fail separately. SchedPilot’s documentation is explicit: “Each platform is handled independently. If you post to LinkedIn, X, and Bluesky in one call and Bluesky fails, LinkedIn and X still publish successfully.” The read-back carries that structure, a status per account rather than one status per post, which is exactly why step four of the test matters. An error in your assistant’s reply does not mean nothing published, and a success does not mean everything did. Per-network quirks make this worse, and they are the subject of posting across platforms.

Which brings us to duplicates. An assistant that gets a timeout will retry, cheerfully, and the first call may already have landed. SchedPilot documents an idempotency_key header for its REST API, described as safe retries that let an agent retry “without creating duplicate posts”. The create call on the MCP surface I enumerated takes no such argument, so inside an assistant conversation that protection is not something you can pass. Your defence is duller: read the queue back before you retry anything, and never let a retry loop run unattended. Runaway loops also cost you the integration, not just the feed, since that is the behaviour Vista Social deactivates keys for.

The approval gate

An assistant with a publish tool and no gate will publish something wrong. Not often. Once. The public version of once is a screenshot with your logo in it.

Three patterns work, in descending order of how hard they are to talk your way around.

• Draft-only tools. The surface has no publishing verb at all, so no prompt, jailbreak or confused loop can reach one. Strongest, because it is a property of the connection, not an instruction inside it.
• Scheduled, never immediate. Everything lands with a future date and a human promotes it. Weaker than it looks: on the surface I enumerated, immediate publication is one boolean on the same call.
• An explicit review step in the product. Drafts queue, a named person approves, then it schedules. SchedPilot documents this route for its API, with approval in the dashboard or through a Slack webhook.

Then ask the question nobody asks: can the assistant be the approver? On Vista Social’s MCP surface, approving is itself a tool. Its help centre lists one that approves or rejects posts waiting in a workflow, and another that returns each workflow’s approvers. A gate the key-holder can call is only a gate if the workflow names somebody else. Check the approver list, not the feature name.

The shape you want is visibility without authority. The listing tool I enumerated filters posts by draft and pending-approval status, so the assistant can see what is waiting and report on it, with no call available that moves anything past the gate. It reads the state and cannot change it.

Gates fail socially more often than technically, which is a longer subject: keeping a human in the loop covers how review turns into rubber-stamping. A reviewer who approves twelve posts in ten seconds is a notification, not a gate. Drafts needing less editing keep a reviewer reading, which is the practical case for giving the assistant a reusable brand voice spec before you widen its reach.

Last thing, and the one I would argue with anyone about. The gate does not belong in the prompt. A system prompt saying “always ask me before publishing” is a preference, and preferences lose to a long conversation, a dropped instruction, or a model update. The gate that holds is a tool list with no publish verb on it, or a key that cannot reach an account you would mind being wrong on. Decide which you have before you paste the key in, not after.