What to check before you let an AI agent post to your social accounts
Ten checks to run before an AI agent posts through a social media MCP server, and a dated table of what 18 vendors’ own docs state about them.
By Mellow · UpdatedShort answer
Before an AI agent posts for you, check what its connection can reach and what stops it: access limited to the channels you pick, a review mode, a daily ceiling, an expiry, revocation that works on the next request and a journal you can read. Then check what prevents public mistakes: idempotency keys, validation that reports every problem before anything is sent, and a separate result for each channel. In our 24 September 2026 check of 18 vendors’ public docs, none stated all three of a review mode, usage limits and an action log, so ask about every gap before you connect an account; the same checklist applies to Mellow Hub, which publishes this page.
The checklist: ten things to verify
Each item says why it matters and how to test it yourself. Use a test account, or drafts and review mode, so that a failed check costs nothing in public. A vendor page tells you what is intended; these tests show what the server actually does.
Access is limited to the channels you choose
Why it matters. An agent that can reach every connected account turns one misread instruction into a post on the wrong brand. The boundary belongs on the credential, where the server enforces it, not in the prompt.
How to verify. Grant one channel, then ask the agent to list its channels and to post to a different one. The list should show only what you granted, and the refusal should come from the server. If the service offers only account-wide keys, note it as a gap.
You choose review or autopilot for each credential
Why it matters. In review mode the agent prepares a post and a person approves what actually goes out; autopilot suits a narrow, repetitive job you have already watched work. A confirmation prompt in the chat app is not the same control: it protects the person at the keyboard, not an unattended run or a second client holding the same key.
How to verify. Create a post with a review-mode credential and confirm that nothing reaches the network until someone approves it in the service. Check that the mode is stored on the key or grant, and that the post that goes out is the one that was reviewed.
A daily ceiling on posts
Why it matters. A loop, a retry storm or a badly split task can publish dozens of times in minutes. A request rate limit protects the vendor’s servers; a posting ceiling protects your accounts.
How to verify. Set a ceiling of two, ask for three posts and expect a clear refusal on the third. Ask whether cancelled or failed posts still count, and whether the agent can read how many posts it has left.
Access expires on its own
Why it matters. Credentials outlive projects. An expiry ends access even when nobody remembers the agent exists.
How to verify. Look for an expiry choice when you create a key or approve an app, then check whether refreshing a token can extend it. A key that lives until someone deletes it is a gap to note.
Revocation works on the next request
Why it matters. When a key leaks or an agent misbehaves, it has to stop now, not when a cache or a session runs out.
How to verify. Revoke the credential, make one more call with it and expect a 401. Then check the queue: revoking a key may not cancel posts it already scheduled.
A journal of actions that you can read
Why it matters. Afterwards you should be able to answer “what did my agent do?” without asking the agent. Refusals matter as much as successes, because they show what it tried.
How to verify. After a test session, open the service’s log and find each action with its time, the credential that took it and the outcome. If the only record is the chat transcript, there is no journal.
A retry cannot publish twice
Why it matters. Timeouts happen, and a request that timed out may still have published. Without an idempotency key, the agent’s natural retry becomes a duplicate post in public.
How to verify. Send the same create request twice with the same idempotency key and expect one post. Send different content with the same key and expect a refusal rather than a silent overwrite.
Validation before sending, with every problem at once
Why it matters. Learning a network’s rules by publishing badly happens in public. Errors reported one at a time also make an agent loop: fix one field, fail on the next.
How to verify. Validate a post that breaks two rules on two networks, such as a caption too long for X and a YouTube video without a title. Expect both problems in one response, each naming the channel and the field, and nothing published.
A result for each channel, with the public link
Why it matters. A single “success” for a post sent to five networks can hide one failure, and retrying the whole post duplicates the four that worked.
How to verify. Publish to two channels where one will fail. Expect a partial status, the failed channel named with the network’s reason, and a public link for the channel that published.
A consent screen that names the grant, and no way to widen it
Why it matters. The grant is the person’s decision. If a credential can create another credential or approve its own post, every limit above is decorative.
How to verify. Read the consent screen: it should name the app, the permissions in plain words, the channels, the mode, the ceiling and the expiry, with a way to refuse. Then, with the agent’s credential, try to create a key and to approve a pending post. Both should be refused.
What 18 vendors’ docs state, checked 24 September 2026
The table records what each vendor’s own public MCP, API and help pages say about the controls above. The list of vendors started from a community roundup of social media MCP servers on r/mcp; every cell was checked again on the vendor’s pages on 24 September 2026, and none was copied from the thread. “Not stated” means we did not find it on the linked pages, not that the product lacks it; ask the vendor before relying on either answer.
Rows are alphabetical. A confirmation prompt shown by the MCP client is a client setting, so it is not counted as a review mode. Mellow Hub publishes this page; its row was checked against its code and is explained below. Prices and tool counts are left out because they change faster than these controls.
| Service | Auth | Runs | Review or approval | Limits | Action log | Sources |
|---|---|---|---|---|---|---|
| Agorapulse | OAuth (an API key option is named for Copilot Studio) | Hosted | Yes: its listed publishing tool creates drafts; replies follow the inbox approval workflow when one is active | Not stated | Not stated | MCP help article |
| Ayrshare | API key (Bearer header only) | Hosted | Yes (API): requiresApproval holds a post until it is approved; the MCP update tool edits posts awaiting approval | Yes: plan-tier rate limits and quotas apply to MCP calls | Not stated | MCP server · Connect · Tools · Approval workflow |
| Blotato | Both (OAuth, or an API key header) | Hosted | Not stated | Yes: per-route request limits, such as 30 post creations a minute | Not stated | MCP setup · MCP FAQ · Rate limits |
| Buffer | Both (OAuth sign-in or personal API key) | Hosted | Drafts; the developer docs say a post can go out immediately and advise keeping the client’s approval prompts on | Yes: request quotas per 15 minutes, 24 hours and 30 days, by plan | Not stated | MCP developer guide · MCP page |
| bundle.social | API key (organization-wide) | Local (npx package over stdio) | Not stated | Yes (API): a daily posting quota per team and per-minute caps | Not stated | MCP page · API introduction |
| Hootsuite | Account sign-in (method not named) | Hosted (one server per product) | Not stated as a setting; the FAQ says organizations keep control of publishing | Not stated | Not stated | MCP page |
| Mellow Hub | Both (OAuth 2.1 with PKCE, or an API key the owner creates) | Hosted | Yes: review or autopilot per key or grant; only a signed-in person approves | Yes: a daily post ceiling per key or grant; OAuth grants expire after 1 to 30 days; keys made on the Agents screen do not | Yes: a journal of writes per credential, on the Agents screen | API and MCP reference · Checked against its code |
| Metricool | Both (OAuth, or a user token and ID for some clients) | Hosted; the server is also open source on PyPI | Not stated (publish now, schedule, or best time) | Yes: plan limits apply, such as no more than 20 scheduled posts on Free | Not stated | MCP FAQ · MCP limits |
| OneUp | Both (API key in the server URL; OAuth in ChatGPT, signed in with the key) | Hosted | Not stated | Not stated | Not stated (a page lists active MCP connections) | MCP connector · ChatGPT setup |
| Planable | Account sign-in (method not named) | Hosted | Yes: posts are created as drafts and go through Planable’s approval workflow; the connector can also approve or reject with your role | Yes: authorization lasts 180 days; plan limits apply | Not stated | MCP connector guide |
| Post Bridge | Both (OAuth, or an API key) | Hosted | Not stated | Yes (API): 10 requests a second per key | Not stated | MCP setup · API reference |
| PostFast | Both (OAuth on the hosted connector, API key for the npm server) | Hosted and local (npm, stdio) | Yes: posts can wait in pending approval; the hosted connector can also approve them | Yes: per key, 60 requests a minute, 150 per 5 minutes, 300 an hour and 2,000 a day | Not stated | MCP page · API docs |
| Postiz | Both (OAuth, or an API key or token as Bearer) | Hosted, or part of a self-hosted Postiz | Drafts; no approval mode stated | Yes (Cloud API): 90 create-post requests an hour | Not stated | MCP docs · MCP page · Limits |
| PostSyncer | Both (OAuth, or a personal access token) | Hosted | Yes: a key without schedule and publish permissions can only create drafts; approving is a separate permission | Yes: 60 API requests a minute; posting unlimited under fair use | Not stated | MCP overview · Key permissions · Limits |
| SocialRobot | Both (OAuth with chosen permissions, or an API key) | Hosted | Not stated (posts land on the calendar and stay editable) | Yes: 15 scheduled posts a month on Free; paid plans uncapped | Not stated | MCP page |
| Typefully | Both (OAuth, or an API key for headless clients) | Hosted | Not stated | Yes (API): per user and per account set; figures not published | Not stated | MCP server · API docs |
| Upload-Post | Both (API key header, or OAuth 2.1) | Hosted; MIT-licensed source | Not stated | Yes: media-staging limits by plan | Not stated | MCP server docs |
| Vista Social | Token inside a copied connect link | Hosted | Not stated (sample prompts approve pending posts through the MCP) | Not stated (the MCP is included from the Advanced plan) | Not stated | MCP page |
| Zernio (formerly Late) | Both (OAuth 2.1 with PKCE, or an API key) | Hosted; can also run locally | Drafts; no approval mode stated | Yes: 60 to 1,200 requests a minute by account count; 25 posts an hour per account; daily caps per network | Yes: activity and API-request logs, filterable by key, kept 90 days | MCP docs · Rate limits · Logs · Rename |
In this check, only Zernio documented an action log, and five vendors documented a way to keep an agent’s post from going out until a person approves it: Agorapulse, Ayrshare, Planable, PostFast and PostSyncer. Most stated a limit of some kind, usually a request rate or a plan quota; none of the pages we read described a posting ceiling that the owner sets for each key or connection.
The help centers of Planable and Vista Social refused automated requests (HTTP 403) on 24 September 2026; those rows rely on the vendors’ product pages linked above.
How Mellow Hub answers the checklist
The same checklist applies to Mellow Hub. Its MCP endpoint is https://www.mellow.world/mcp. A client connects over OAuth 2.1 with dynamic client registration and PKCE (S256), or with an API key the owner created in Hub, and a request without a credential gets a 401 that says where to authorize and which scopes to ask for. The answers below come from Hub’s code; the status column says where Hub falls short.
| Check | What Mellow Hub does | Status |
|---|---|---|
| 1. Channels you choose | An OAuth grant reaches only the channels ticked on the consent screen or, as an explicit choice, all current and future channels in the profile; an empty selection never becomes “all”. A channel outside the grant is refused in validation, previews and stored posts. A key created on the Agents screen reaches every channel in its profile, because the key form has no channel choice. | Partly |
| 2. Review or autopilot | Every key and grant carries a mode. In review, create_post saves the post as waiting for approval and sends nothing, and approval publishes the stored post, so what goes out is what was reviewed. The consent screen starts on Review and the key form starts with review ticked. An OAuth grant’s mode changes only by revoking it and authorizing again. | Yes |
| 3. Daily ceiling | Every key and grant has a ceiling over a rolling 24 hours: 1 to 1,000 on the consent screen, 1 to 500 in the key form, 50 by default. It is checked in the same database transaction that saves the post, and a cancelled or failed post still counts. whoami tells the agent how many posts it has left today. | Yes |
| 4. Expiry | An OAuth grant ends after 1, 7 or 30 days (7 by default), and refreshing a token cannot extend it. A key created on the Agents screen has no expiry and works until it is revoked. | Partly |
| 5. Revocation | Every request re-reads the key or token, so a revoked credential gets a 401 on its next call. Disconnecting an app revokes all of its tokens and unused authorization codes, and reusing an already-rotated refresh token revokes the whole grant. Posts a credential has already scheduled stay scheduled until someone cancels them. | Yes |
| 6. Journal | Writes made with a key or grant, such as creating, rescheduling or cancelling a post, are recorded in hub_audit_events with the credential, the post or network where relevant, and the outcome; refused posts are recorded too. Reads and validation are not recorded, and captions, media and credentials never are. The entry for a new post is saved in the same transaction as the post; other entries are best-effort. The Agents screen shows only the latest entries, with no search or export. | Yes, with limits |
| 7. Retries | create_post requires an idempotency key of 8 to 120 characters. The same key with the same content returns the original post; the same key with different content is refused with idempotency_key_reused. Hub’s own re-sends are covered too: before creating a post at its publishing provider, it looks for one carrying Hub’s post ID and adopts it, so a send interrupted by a timeout is not published twice. | Yes |
| 8. Validation | validate_post is free, publishes nothing and returns every problem at once, each naming the channel and the field; create_post runs the same checks before anything is sent. It cannot judge the file itself, such as its resolution or duration, which the network decides after upload. | Yes |
| 9. Per-channel results | get_post returns each channel’s status with its public link or the network’s error. A mix of successes and failures is reported as partial, and the documented recovery retries only the failed channel, with a new idempotency key. | Yes |
| 10. Consent, no self-escalation | The consent screen names the app, lists the permissions in plain words with only “see connected channels” and “read posts and their results” pre-selected, and asks for the mode, the channels, a daily ceiling and an expiry; nothing is issued until the person presses Allow. Creating or listing keys, reading the journal and approving a post all require a signed-in person, so any key or token is refused. The first 401 lists the scopes to request and leaves out the one that spends AI credits. | Yes |
For a narrow or temporary job, connect the agent through its client’s OAuth flow rather than with a key: the consent screen asks for channels and an expiry, and the key form does not. Either way, a credential stays inside the profile that issued it and cannot switch to another. These answers describe Hub’s controls; they are not a claim that every network and account type has passed an end-to-end publishing test. Tools, scopes and error codes are in the API and MCP reference.
Questions
Is it safe to let Claude post to Instagram?
It can be, if the connection is a narrow delegation rather than your whole account. Connect the Instagram account in the publishing service yourself, then give Claude access over OAuth to that one channel, in review mode, with a low daily ceiling and an expiry. Check that you can read a log of what it did and revoke its access in one step. Claude never needs your Instagram password.
Should I choose review or autopilot?
Start with review: the agent prepares each post and a person approves it in the service before anything is sent. Move one narrow, repetitive job to autopilot only after you have watched it work, and give that credential a low daily ceiling and a short expiry.
What happens if the agent retries after a timeout?
Without an idempotency key, a retry can publish the same post twice, because the first request may have gone through. With one, the server recognizes the repeat and returns the original post. Derive the key from the task or the content rather than generating a new one per attempt, and expect a refusal if the same key is reused for different content.
Is the confirmation prompt in my AI app enough?
No. The prompt asks whoever is at the keyboard before a tool runs, and it can be switched off; an unattended run or another client holding the same key is not bound by it. A review mode on the server holds the post until a person approves it in the service, whichever client sent it.
How do I take access away from an agent?
Delete the key or disconnect the app in the publishing service, not only in the chat app, then make one more request with the old credential to confirm it is refused. Revoking access may leave posts that were already scheduled in the queue, so check it and cancel anything that should not go out. In Mellow Hub, keys and connected apps are revoked on the Agents screen and stop working on their next request.
Related
- Publish to social media with an MCP server: connect an agent, validate, schedule and check each channel’s result.
- Instagram MCP: account requirements, login paths and tested post inputs.
- A social media approval workflow: review an AI-prepared post before it goes out.
- API and MCP reference: every tool, scope and error code.
- Mellow Hub plans: profiles, publication allowances and prices.