The best social media MCP servers, compared

If you want Claude, Cursor or ChatGPT to actually publish a post rather than just draft one, you need an MCP server sitting between the agent and the platforms. Several now exist. They differ more than the marketing suggests.

We build one of them, so read this with that in mind. Everything below was read off each vendor’s own pages on 6 September 2026, and where a vendor does not publish a number this says so rather than guessing.

What an MCP server actually is

Model Context Protocol is a wire format for handing an AI client a set of callable functions. A server advertises a list of tools. Each tool carries a name, a natural-language description, and a JSON Schema describing its arguments. The client — Claude Desktop, Claude Code, Cursor, ChatGPT, an IDE, an automation runner — reads that list when it connects, puts it in front of the model, and executes whichever tool the model chooses with whichever arguments the model fills in. There is nothing magic in the protocol. Everything interesting is in what the tools are and how they are described.

For a scheduler specifically, the MCP server is a thin shell around the same REST API the web dashboard already calls. Connecting an account, registering an uploaded image, creating a draft, scheduling it for a timestamp, listing what is queued, reading back what happened — all of that exists as HTTP endpoints long before anyone writes an MCP server. The engineering work is not plumbing. It is deciding which endpoints deserve to be tools at all, what each one is called, and what its description says about when to reach for it. Those three decisions are the entire product.

Two transport shapes exist and it is worth knowing which one you are being sold. A local stdio server runs on your machine as a subprocess of the client and reads credentials out of a config file you control. A remote HTTP server is a URL you point the client at, normally behind OAuth, and your credentials never leave the vendor. Hosted schedulers ship the second almost universally. That has a consequence people miss: the tool list is whatever the vendor has deployed at the moment you connect, and it can change under you between one session and the next without you doing anything.

One more piece of vocabulary, because vendors use it loosely. Tools are the callable functions. Resources are read-only documents the client can pull in. Prompts are pre-written templates the client can offer as slash commands. Most scheduler servers are tools-only, so when a vendor publishes a number, it is almost certainly a tool count and not a total of all three.

The short version

• Buffer — MCP on every plan including the free one. Tool count not published.
• Metricool — MCP on every plan including the free one, 20+ tools. Analytics-led.
• Blotato — 35 tools, strong agent focus. Its 7-day trial excludes MCP.
• Post Bridge — 13 tools, setup documented for around nine clients.
• Postiz — MCP plus an agents CLI, open source and self-hostable. Tool count not published.
• seenpaid — 50 tools, and the only one that can tell the agent what a post earned.

If you want it free: Buffer or Metricool

Both include MCP access on their free plans. That is a genuinely strong offer and neither of the two is beatable on price, including by us — ours has no free tier and asks for a card for its 7-day trial.

Buffer covers 11 platforms and lists Claude, ChatGPT, Cursor, Raycast, Perplexity, Notion, Zapier, n8n, Manus and Antigravity as clients. It does not publish a tool count, so if the size of the tool surface matters to you, you will have to connect it and look.

Metricool is the analytics-heavy option: 20+ tools, 12 platforms, and reporting depth no scheduler matches — competitor tracking across up to 100 profiles, ad-platform reporting, a Looker Studio connector. If your agent’s job is to read numbers rather than publish, it is the better pick.

If you want the biggest agent surface: Blotato, with one caveat

Blotato publishes 35 tools and a REST API alongside the MCP server, and supports Claude, Claude Code, Claude Cowork, ChatGPT, Cursor, Codex, Antigravity and Replit Agent. On the agent axis it is the most serious of the incumbents.

The caveat is worth knowing before you start: by their own documentation the 7-day trial excludes the API and MCP, and generating an API key ends the trial and starts the paid Starter subscription immediately. So you cannot actually evaluate the agent features for free. That is a real thing to plan around, not a criticism — but it surprises people.

If you want to self-host: Postiz

Postiz is open source under AGPL-3.0 with 35.5k GitHub stars and can be run on your own infrastructure. It also supports more platforms than anyone here — 30+, including Nostr, Warpcast, Lemmy, Dev.to and Hashnode. If avoiding vendor lock-in is the requirement, nothing else on this list competes and you should stop reading here.

It ships MCP plus an agents CLI, though it does not publish a tool count either. Self-hosting also changes the transport question above: you are the vendor, the server is on your infrastructure, and the tool list only changes when you deploy.

If you want the setup documented for your exact client: Post Bridge

13 tools, 10 platforms, and connection instructions written out for around nine named clients including Windsurf and Grok. Fewer tools than most here, but the least friction if your client is an unusual one.

What makes a tool surface good rather than merely large

Tool count is the number everyone quotes because it is the only one that is easy to publish. It is a weak proxy for usefulness. A model does not benefit from having more tools available; it benefits from having tools that map cleanly onto the things it is being asked to do. It is actively harmed by tools it has to disambiguate between under time pressure, because every ambiguous choice is a chance to pick wrong.

Bloat shows up in recognisable ways, and you can spot most of them from the tool list alone:

• Overlapping writes. Two tools that do nearly the same thing force the model to guess, and it will guess differently on different runs. One create-a-post tool with optional arguments beats three near-identical ones.
• Under-specified arguments. A scheduling tool that accepts a free-text time string instead of an ISO-8601 timestamp plus an explicit timezone will eventually post at the wrong hour, and the failure looks like the model being careless rather than the schema being loose.
• Missing read-backs. A server that can create a post but cannot list posts leaves the agent unable to check its own work. The visible symptom is duplicates: the model cannot confirm the first call landed, so it tries again.
• Descriptions written for humans. In MCP the description field is prompt, not documentation. A description that only says what the tool does, and never says when not to use it, will get the tool called in situations it was never meant for.
• No validation path. Every platform has its own caption limits, media requirements and aspect-ratio rules. If the only way for the agent to discover them is to fail a publish, you are burning real posts on real accounts to learn rules that could have been returned by a read-only call.
• No idempotency story. Agents retry. If nothing in the surface lets a retry be recognised as a retry, network flakiness becomes double-posting.

The good version of a large surface is one where most of the extra tools are reads. Writes should be few, unambiguous and destructive-by-explicit-argument only. Reads can be plentiful without costing anything, because a wrong read wastes a round trip and a wrong write wastes your audience’s attention. When you see a big number, the question to ask is what the read-to-write ratio is.

How to evaluate one yourself

You do not need a spreadsheet of vendor claims. Connect the server and run it through a short, deliberately awkward sequence. This takes about twenty minutes and tells you more than any comparison post, including this one.

• Ask the client to list the connected tools verbatim. You now have the real count and the real names, which is the only way to check a published number.
• Read five tool descriptions in full. If they read like API reference docs rather than instructions to a colleague, the model will misuse them.
• Ask for something that needs two steps — schedule a post, then tell me what is queued for next week. A surface that cannot read back its own writes will fail here, usually by confidently asserting success it cannot verify.
• Ask it to do something the platform forbids, such as a text-only Instagram post. A good surface refuses before the API call with a reason. A weak one attempts it and returns a raw platform error.
• Ask it to schedule something in a timezone that is not yours. Vague time handling surfaces immediately.
• Ask it to delete something, and watch whether it confirms first. Then check whether the delete was soft or hard.
• Disconnect and reconnect. Note whether the account survived, and whether the tool list came back identical.

Score what you saw, not what was advertised. The single most predictive signal is whether the agent could answer a question about work it had just done, because that is the loop everything else is built on.

What every one of them has in common

They publish. That is the whole job description, and once the post is out the agent is blind. It can tell you a post went live. It cannot tell you the post produced a sale, because none of these servers connect to a payment processor.

That is the gap seenpaid was built for. It exposes 50 tools — more than any competitor here that publishes a count — across 21 platforms, and among them are tools that read revenue: what an individual post earned, which channel returns the most per post, which posts got clicks but produced no sales. The agent can ask "what should I do more of" and get an answer denominated in dollars rather than likes.

Mechanically that works the way you would guess. Each scheduled post carries a tracked link; clicks on it are stamped with the post that produced them; the customer’s own payment processor is read through a separate read-only connection; and a payment that follows a stamped click within the attribution window is joined back to the post. The reason no scheduler does this by default is not difficulty — it is that a scheduler has no reason to ask for access to your payments, and asking for it is a real trust cost.

The honest limits of this comparison

Three of them, stated plainly, because a comparison written by a participant is worth exactly as much as the caveats it volunteers.

• Tool counts are self-reported and not defined the same way twice. One vendor may count a read and its paginated variant as two tools where another counts one. Comparing them is comparing labels, not capability.
• Buffer and Postiz ship MCP without publishing tool counts, so any "most tools" claim — ours included — is only a claim against the vendors who publish one.
• Postiz supports more platforms than we do, 30+ against 23. If breadth is what you are optimising for, we are not the answer, and no amount of tooling closes a platform gap.

There is also a limit that applies to the whole category: none of these numbers measure reliability. A server with 50 tools that times out under load is worse than one with 13 that does not, and no vendor publishes their error rate. That is what the twenty-minute test above is really for.

How to choose

• You want it free → Buffer or Metricool.
• You want to self-host, or you need a platform nobody else covers → Postiz.
• You want the deepest analytics → Metricool.
• You want the widest agent tooling from an incumbent → Blotato, budgeting for the trial caveat.
• You want your agent to know which posts made money → ours.

The last one is not a general recommendation. If you do not sell anything, revenue attribution is worth nothing to you and one of the free options is the better answer.