TL;DR: An MCP server for publishing gives your AI client a tool to post content on your behalf. Most of them call official platform APIs from the cloud, so they only reach platforms that hand out an API key: X, LinkedIn, Facebook. PublishPort instead gives the AI a
local_bashtool that drives the same CLI and login session sitting on your own machine, which also covers platforms with no public API at all, like Xiaohongshu or Douyin.
Search “MCP server for social media” and you get a wall of near-identical entries: nine, ten, sometimes twenty listed side by side, each claiming to let Claude post on your behalf. Pick one, wire it in, and the first thing you notice is the platform list. X, LinkedIn, Facebook, Instagram if you pay for the right tier. Ask it to post to Xiaohongshu or a Chinese platform and it has nothing to offer, because there’s no button for that inside its architecture at all.
That gap isn’t a bug in any one server. It’s the shape of the model almost all of them share.
What a “social media MCP server” usually is
Under the hood, most publishing MCP servers are a thin wrapper around official platform APIs. Ayrshare exposes 75+ tools across 13+ platforms, gated behind its own paid API plan starting at $149/mo. Blotato posts out of the box to Facebook, Instagram, YouTube, TikTok, LinkedIn, Threads, and X. Zernio goes wider, claiming 280+ tools across 15 networks and 7 ad platforms. Postiz covers 30+ platforms and, notably, recommends a human review step before anything actually publishes.
That’s a reasonable architecture: your AI client calls a tool, the server translates it into an API call, the platform’s own backend does the posting. It’s also why the pitch and the platform list look nearly interchangeable across vendors: whoever has the API access wins that platform, full stop.
Where the API model runs out of platforms
The API model only reaches as far as the APIs exist. Xiaohongshu, Douyin, and most short-video and lifestyle apps in the Chinese market don’t publish a “post on my behalf” endpoint at all. Even Reddit, which does have a public API, locked down free access for third-party apps back in 2023, so a server that only speaks API can be one pricing change away from losing a platform it used to cover.
For those platforms, every publishing tool, MCP-based or not, ends up driving the actual web app: logging in through a browser, filling the composer, clicking submit. The question is just whose browser session that is, and where it’s running.
A packaging standard just shipped. It doesn’t touch this problem
On August 6, 2026, Vercel published Agent Plugins 1.0.0, an open format that bundles Agent Skills and MCP server configuration into one installable folder: a plugin.json manifest, an optional skills/ directory, an optional mcp.json, and a namespaced folder for anything client-specific. AWS, Cursor’s maker Anysphere, GitHub, Microsoft, and OpenAI helped shape the 1.0 spec, Google joined as a core maintainer the same day, and six clients (ChatGPT, Codex, Cursor, GitHub Copilot, Kiro, and VS Code) supported it at launch.
Worth noting who isn’t in that list: Anthropic. Claude popularized the MCP-plus-Skills combination this standard packages, but it isn’t one of the core maintainers and Claude Desktop wasn’t among the six launch clients. That’s a real fork in how the ecosystem is organizing itself, not a detail to gloss over if you’re betting a workflow on one side of it.
For a publishing MCP server specifically, Agent Plugins solves distribution, not capability. It gives a server author one folder that several IDEs and agent clients can install instead of five separate setup guides. It doesn’t change which platforms that server can actually reach, and it doesn’t touch the API-availability gap described above. A beautifully packaged plugin that only wraps X and LinkedIn’s official APIs still only reaches X and LinkedIn.
It also doesn’t change PublishPort’s own shape. There’s no plugin.json to write here, because there’s no fixed tool-per-platform list to enumerate in one. The AI discovers what’s available by calling list_capabilities() and reading a CLI’s own --help at runtime, so a new platform ships without a manifest update on either side. That’s less a rejection of Agent Plugins than a different problem: the standard packages a known, static set of tools for portability, and PublishPort’s set of usable commands grows as upstream CLIs add platforms.
PublishPort’s shape: fewer tools, more surface
PublishPort’s MCP server doesn’t register one tool per platform action. It registers a handful of general ones and lets the AI drive the same CLI a human would use, PublishPort’s ppcli, on your own machine:
list_capabilities: what platforms are connected on this device, and their live login state.local_bash: run a shell command on the device (this is how the actual publish call happens; the AI reads<tool> --helpand drives it directly).publish_guide: a per-platform cheat sheet plus the live--helpoutput, so the AI doesn’t burn a round trip guessing flags.write_local_text/read_local_text: drop a draft’s body straight into a file on the device (so a publish command can point--fileat it instead of stuffing a whole article into a shell argument), then read a small text file back.prepare_upload/read_local_file: the same round trip for anything bigger than a text file, images and video, without the relay ever storing the bytes.publish_receipt: called once a publish attempt is done, success or not. It puts a result card with post links in your notification center and, separately, sends the friction points back to us so the CLI or the guide gets fixed.notify: a lighter, in-progress heads-up (for example, before the AI tries a platform for the first time), separate from a publish outcome.report_discovery: what the AI calls when it works out how to post to a platform outside the current list at all. That report is the raw material we turn into the next official adapter, which is also how the platform list in this post keeps growing without you waiting on us to prioritize it.
That’s the trade PublishPort makes: instead of a tool schema hardcoded per platform, the AI is the adapter and --help is the schema. It costs nothing per new platform beyond wiring in the upstream open-source CLI, so it isn’t gated by which platform decided to sell API access this year. You can download the client and see the live capability list for your own accounts once a platform is connected.
Wiring it into Claude or any MCP client
Under the hood this is a remote, HTTP-based MCP server, not a local process spawned from a config file, so the setup is closer to adding a connector than pasting a stdio command. Four steps, per the docs:
- Install the PublishPort desktop client and sign in.
- Log in to each platform through your real browser inside the client. A connected account turns green.
- Start the local executor so your machine can reach the relay.
- Copy the generated MCP endpoint and add it to Claude, or any MCP-capable client, as a remote server.
From there, the AI calls list_capabilities() the same way it would call any other MCP tool. Whether your client stores that as a URL-type entry or something else is a client detail; the endpoint itself is what matters, and it’s also the only credential in this whole chain. Treat it like a password: rotate it if you think it leaked.
The security question worth asking before you connect anything
Search around and you’ll find a real, ongoing conversation about MCP server security: prompt injection through tool responses, supply-chain risk in server packages, servers that quietly grant far more than a chat client should have. A local_bash-shaped tool is the sharpest version of that question, because it is, by construction, remote command execution against your own computer. There’s no polite way to soften that fact, so we won’t.
What actually gates it: every command passes a denylist first (an unconditional block on things like credential exfiltration, privilege escalation, or destructive filesystem operations), and anything that isn’t explicitly denylisted or explicitly safelisted goes through an AI review step that fails closed, meaning it gets rejected by default unless it’s judged safe. Both layers can be switched off in the client if you want fewer guardrails, but they’re on by default. None of that replaces the one hard boundary: the MCP endpoint is the single key to all of it, and whoever holds it can run commands on that machine through the relay.
If you’re evaluating this for a team rather than yourself, that single-endpoint model is worth naming as a real tradeoff, not glossing over. Anthropic shipped enterprise-managed authorization for Claude’s MCP connectors on August 24, 2026, letting an admin provision access through an identity provider so employees inherit a connector on first login instead of each person authorizing it by hand. That solves per-user OAuth friction for API-backed connectors like Slack or Notion. A device-bound endpoint like PublishPort’s is a different shape of problem: it isn’t per-user OAuth to begin with, so rolling it out to more than one person on a team means deciding who holds that endpoint and how it gets rotated, not provisioning individual logins.
FAQ
Is it safe to let an AI run commands through an MCP server?
It depends entirely on what gates the command execution, not on the label “MCP.” A server that exposes shell access needs a real filter in front of it (a denylist for destructive operations plus a review step for anything ambiguous) and a single, rotatable credential gating the whole connection. Ask what actually gates that access, not just whether the server “supports” a tool.
What’s the difference between an MCP server that calls an API and one that drives a local CLI?
An API-based server posts through the platform’s official backend from wherever the server runs, usually a cloud host, and is limited to platforms that hand out that API. A local-execution server drives the actual app or CLI through a session already logged in on a specific device, which also covers platforms that never shipped a publishing API.
Which MCP clients can connect to a remote MCP server like this?
Claude Desktop and Claude.ai both support remote MCP connections, and so do several other clients including Cursor and VS Code extensions built for MCP. The exact steps to add one differ per client, but all of them boil down to giving the client the server’s address.
Can an MCP server publish to platforms with no public API, like Xiaohongshu or Douyin?
Only if it’s driving the platform the way a person would, through a logged-in browser or app session, rather than calling an API that doesn’t exist. That’s the entire reason PublishPort’s tools are shaped around local_bash instead of a per-platform publish endpoint.
Does using a local MCP server protect my account from getting banned?
It changes the odds by removing the most obvious automation signals, a shared data-center IP and a fresh, disposable session, but it isn’t immunity. Platforms still watch posting frequency and content, and a real machine posting too fast still looks like a bot.
What happens if the AI tries to post somewhere PublishPort doesn’t officially support yet?
It can still try, driving the platform’s real site the same way a person would, and then files a report back to PublishPort through a dedicated tool once it’s done. That report, what worked and what broke, is exactly the input we turn into the next official adapter, so the platform list grows from real attempts instead of a fixed roadmap.
Does Agent Plugins 1.0.0 change how MCP publishing servers work?
No, it changes how they’re packaged and installed, not what platforms they can reach. Agent Plugins bundles Agent Skills and MCP configuration into one folder that clients like ChatGPT, Cursor, and VS Code can install directly, but a publishing server wrapped in that format still needs its own capability, either an official API or a driven browser session, to actually reach a given platform.
We wrote about the reasoning behind local execution in more depth in why local-environment publishing beats cloud automation, and about the end-to-end publishing flow in letting an AI agent publish to Xiaohongshu, Douyin, and more. If something above is out of date, the docs are the source of truth.