How to choose a social media MCP server

Search npm for an MCP server that posts to social media and you will find plenty. Install a few and a pattern emerges quickly: most are a thin wrapper around one network’s POST endpoint, published in an afternoon, with a single tool called something like post_tweet.

Those are genuinely useful for a demo. They are not useful for a workflow you leave running, and the gap between the two is not obvious until something fails at 2am. This is the checklist we use — including on our own MCP server, where several of these items exist because the earlier version did not have them.

1. Does it cover more than one network?

The single-network server has a hidden cost: it does not compose. Running one server for X, one for LinkedIn and one for Bluesky means three API keys, three auth flows, three sets of tool names in the model’s context window, and three different mental models for what “schedule” means.

It also makes the most common real instruction — “post this everywhere” — into a manual fan-out the model has to orchestrate across servers, with no shared record of what succeeded. One server covering all seven networks turns that into one call.

2. Is there a dry run?

This is the single biggest differentiator, and almost nobody has it.

A language model writing a post does not know that X cuts off at 280 characters, that the Instagram account you named is not actually connected, or that this particular post will cost 55 credits because it contains a link. Without a dry-run tool it finds out by failing at publish time — which, if the post was scheduled for Tuesday, means it finds out on Tuesday.

preflight_post runs the whole validation path and publishes nothing. It reports limit overflows per network, unconnected profiles, missing media and the exact credit cost. The model calls it, sees the copy is 34 characters too long for X, rewrites, and only then commits.

3. One post per profile, or one post fanned out?

A subtle architectural choice with large operational consequences. If “post to LinkedIn and X” creates one record with two destinations, then LinkedIn failing leaves you with a half-delivered object that is awkward to retry — retrying risks double-posting to X.

If it creates two records, each with its own id and status, then each can be edited, retried or cancelled independently. Retrying the failed LinkedIn post cannot touch the delivered X post. This is what you want, and it is worth checking for explicitly.

4. Does it tell you when tokens are dying?

The most common failure mode in any social automation is not a bug. It is an OAuth token that expired weeks ago while nothing was watching. Meta tokens in particular have a habit of going stale, and the symptom is not an error — it is posts that quietly stop appearing.

A get_account_health tool turns that from a mystery into a question the agent can answer on a schedule: “anything need reconnecting this week?” Servers without it will happily accept posts for accounts that cannot receive them.

5. Can it batch?

A week of content across four networks is around thirty tool calls. Done one at a time, that is thirty approval prompts and thirty round trips, and any failure halfway leaves an ambiguous state.

A multicall tool that takes up to twenty operations, validates every tool name before executing anything, and returns a per-call result makes the same job one approval. The validate-first part matters: a typo in call nineteen should not leave you with eighteen posts written and no clean way to reason about the rest.

{
  "calls": [
    { "id": "img", "tool": "generate_image",
      "arguments": { "prompt": "launch banner" } },
    { "tool": "create_post", "arguments": {
        "content": "We shipped it 🚀",
        "targetAccounts": [
          { "platform": "linkedin", "profileId": "lin_7741903" },
          { "platform": "twitter",  "profileId": "tw_1293847" }
        ],
        "scheduleDate": "2026-09-01",
        "scheduleTime": "10:00",
        "timezone": "Asia/Kolkata"
    } }
  ],
  "stopOnError": true
}

6. Does it support both transports?

stdio-only servers cannot be used from web clients. HTTP-only servers force you to host something before you can try anything. A server that ships both from one binary — stdio by default, streamable HTTP when a PORT is set — means the thing you tested locally in Cursor is the same thing you deploy for Claude.ai.

7. Is the write surface separated from the read surface?

Clients gate tool calls behind approval, and users approve faster than they read. A server that names and groups its tools so that reads are obviously reads makes “always allow” a safe choice for the harmless half, which in turn means the approval prompt on create_post still gets attention when it appears.

A flat list of sixteen similarly-named tools trains people to click through everything. Design that makes the dangerous thing look different from the safe thing is a security feature.

8. What happens when a platform says no?

Every network has its own quirks — media rules, aspect ratios, rate limits, duplicate-content rejections. The question is what the server does with the platform’s error.

Swallowing it and returning a generic failure makes the agent guess. Surfacing the per-profile error verbatim, alongside a reset_stuck_post escape hatch for a post caught mid-publish, lets the agent read the actual reason and fix it. Look for get_post returning per-profile errors rather than a single status field.

9. Can you read the source?

You are handing this thing an API key that can publish under your name. Being able to read exactly what each tool sends — and fork it if you disagree — is not a nice-to-have. Prefer MIT-licensed servers published under a scoped npm name you can trace back to the vendor, and check that the repository is real rather than a stub.

The short version

PostMCP’s server was built against this list — sixteen tools across seven networks, MIT licensed, both transports from one binary. The tool catalogue has the full surface, and for developers covers the REST side if you would rather not route through a model at all.