My AI fleet posts to five platforms — X, LinkedIn, Meta (Instagram/Facebook), Threads, and Dev.to. When I went looking for how to wire that up, I expected to build something from scratch. Instead I found a genuinely crowded market: Socialync covers eight platforms in one server, Publora covers eight more, SocialPilot and Buffer both ship their own multi-platform MCP stacks. The "do everything in one server" pattern is already the commercial default.
I didn't do that. I built five separate, minimal servers — one per platform — and I want to explain why, because it wasn't about being first. It was about a trade-off I kept hitting once agents started actually using these tools in production.
What "minimal" bought me
Each server does one platform's real API, nothing else. No unified abstraction layer pretending X and LinkedIn work the same way (they don't). No shared auth store across platforms I don't fully trust with each other's tokens. When X's OAuth2 flow needed token rotation logic, that lived in exactly one file, touched by exactly one server, with a blast radius of one platform if I got it wrong.
The alternative — a single mega-server proxying eight platforms — means one dependency update, one auth bug, or one rate-limit misconfiguration can take down posting across everything at once. For a one-person studio running an agent fleet unattended, that's not a hypothetical: an agent that can't tell the difference between "X is down" and "my auth layer broke" burns hours I don't have.
The platform-specific gotchas that justified separate servers
X (Twitter): OAuth2 with token rotation — refresh tokens expire and need to be re-issued correctly or every subsequent call silently fails. Isolating this in its own server meant one clear failure surface instead of a shared auth module that has to reason about five providers' different expiry semantics at once.
Meta (Instagram/Facebook): scope gotchas that don't show up until runtime — a token that works for page posts can fail silently for Instagram publishing if the scope wasn't requested up front. Debugging that inside a generalized server means guessing which platform's scope model you're actually looking at. In a single-platform server, the scope requirements are the entire file.
LinkedIn: the UGC post API has a real processing delay between submission and the post actually going live — long enough that a naive "post and confirm" loop returns before the post exists. That's a LinkedIn-specific quirk with no equivalent on X or Threads; baking a wait/retry pattern for it into a shared posting abstraction is exactly how those abstractions get bloated and fragile.
Dev.to: the API's own publish-state gate — everything created through it lands as a draft, full stop, no argument flips it live. That's a deliberate safety property I want preserved exactly as-is, not smoothed over by a generic "publish" method that has to special-case it anyway.
Threads: newest of the five APIs I integrated, still evolving faster than the others. Keeping it isolated meant I could iterate on it without touching four other working integrations.
Every one of those is a reason a shared abstraction gets complicated fast. Multiply by five platforms and the "unified" server either becomes a pile of platform-specific branches wearing one interface, or it flattens the differences and breaks in ways that are hard to debug because you don't know which platform's assumptions just got violated.
What minimal did NOT save me
I'll be honest about the cost: five servers means five things to keep running, five sets of credentials to rotate, five codebases (small as they are) to keep in sync with each provider's API changes. If you're integrating one or two platforms, a single server is probably still the right call — this only paid off because I had five and they diverged enough to matter.
It's also worth saying plainly: if you just need "post to everywhere" and don't care about isolating failure domains, the commercial multi-platform options (Postiz is the strongest open-source one I've seen mentioned; Ayrshare if you want a developer-facing API) will get you there faster than building anything yourself.
Where this leaves me
None of the five servers is trying to be a product — they're internal infrastructure for a fleet of agents that need to reliably post without me babysitting auth tokens across platforms that don't agree on how auth should work. The architectural bet was: keep the blast radius of any one platform's weirdness contained to that platform's own server, and accept the operational overhead of running five small things instead of one big one.
If you're building agent tooling that touches more than two or three platforms with genuinely different APIs, that trade-off is worth thinking through before you reach for the all-in-one server — even though, as it turns out, most of the market already has.
This post was written with AI assistance as part of an active AI agent workflow — the fleet described here is real and running.
If you found this article helpful or informative, please consider supporting us by visiting our creative sister brand, With Nate on Etsy.
Top comments (0)