Why Every AI Agent Eventually Fights Social Media APIs

Eugeniya Ivanova — Tue, 07 Jul 2026 13:29:35 +0000

AI agents have gotten weirdly good at writing.
You can hand one a vague prompt and get back something publishable. The trouble starts one step later, when you ask it to actually press "post."
"Post this to LinkedIn" sounds like one API call. In practice it's multiple OAuth flows, a few different media upload pipelines, review-gated permissions, token refresh logic, rate limits, and a scheduler for the moment you decide you'd rather not publish at 3am.
The model isn't the hard part anymore.
The integrations are.
If you're building agents that publish, here's what that landscape actually looks like.

One network? Native is great.

Let's start with the easy case. Posting to Bluesky via the AT Protocol is refreshingly straightforward.

# Create a session
curl -X POST https://bsky.social/xrpc/com.atproto.server.createSession \
  -H "Content-Type: application/json" \
  -d '{"identifier":"you.bsky.social","password":"'"$BLUESKY_APP_PASSWORD"'"}'

# Create a post
curl -X POST https://bsky.social/xrpc/com.atproto.repo.createRecord \
  -H "Authorization: Bearer $ACCESS_JWT" \
  -H "Content-Type: application/json" \
  -d '{
    "repo": "<your-did>",
    "collection": "app.bsky.feed.post",
    "record": {
      "text": "Hello Bluesky 👋",
      "createdAt": "2026-07-10T09:00:00Z"
    }
  }'

Two requests. That's the whole thing.
Now imagine doing that for LinkedIn, X, Instagram, Facebook, Threads, and Mastodon—none of which were designed together, or, from the look of it, designed to be aware the others exist.
There isn't really a "social media API." There are half a dozen unrelated APIs that happen to share a hobby.

Every platform has its own rules

Platform	Authentication	Biggest friction
LinkedIn	OAuth 2.0	App review for advanced publishing
X	OAuth 2.0	Pay-per-use since Feb 2026 — ~$0.015/post, $0.20 if it has a link
Instagram / Facebook / Threads	Meta Graph API	Business account + App Review
Bluesky	App password or OAuth	Almost no friction
Mastodon	Token per instance	Every instance is effectively its own API

The pattern shows up fast. Open networks like Bluesky and Mastodon are easy to build against; the big commercial platforms want app reviews, business verification, paid access, or all three.
X earns its own line here. Writing isn't just paid—it's paid per link. A plain post runs about $0.015, but a post with a URL costs $0.20. Which is a delightful surprise for an agent whose entire job is sharing links. You built automation to save time, and now it's quietly running up a tab, twenty cents at a time.

The integration work sneaks up on you

Generating content is easy. Keeping the integrations alive is the actual job.
Every platform authenticates differently, uploads media differently, scopes differently, fails differently, and expires its tokens on its own private schedule. Scheduling, half the time, isn't supported at all.
At some point your AI project quietly turns into an OAuth project.

Where MCP fits

One way out is to stop teaching the agent about every platform individually, and instead expose publishing as a single tool.

With the Model Context Protocol (MCP), an agent discovers available tools with tools/list and calls them with tools/call. Under the hood it's plain JSON-RPC.

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "create_post",
    "arguments": {
      "content": "Hello from an agent 👋",
      "platforms": [
        "linkedin",
        "bluesky"
      ],
      "scheduledTime": "2026-07-10T09:00:00Z"
    }
  }
}

The interesting part isn't MCP itself. It's the abstraction.

The agent calls one tool. Something behind that tool deals with OAuth, retries, uploads, scheduling, and whatever mood each platform is in today.

It's a pattern engineers already know by heart: hide the provider-specific mess behind a stable interface, and try not to look at it too often.

I'm skipping the protocol tour on purpose—teaching MCP from scratch would pull this post somewhere it doesn't need to go. If you want the proper walkthrough of tools/list, tools/call, and the JSON-RPC plumbing underneath, other people have already done it well:

楊東霖

Mar 20

MCP Server Tutorial: Build Your First Model Context Protocol Server Step by Step

#webdev #programming #tools #productivity

18 min read

…and the official MCP docs are the canonical reference. No point in me repeating what they cover better.

Connecting an MCP server

A hosted MCP server is usually just an endpoint and a key. Here's how I connect the one we built at Publora:

claude mcp add publora \
  --transport http https://mcp.publora.com \
  --header "Authorization: Bearer $PUBLORA_API_KEY"

Publora, your own server, someone else's implementation—it doesn't matter for the point. The architecture stays the same: your agent calls one tool instead of maintaining a relationship with five different APIs.

Things that cost far more time than expected

Scheduling
Most APIs publish immediately. If you want scheduled posts, you're building a queue, retries, and a scheduler yourself—congratulations, you now maintain infrastructure.

Media uploads
Uploading media is almost never one request. Usually it's three:

Ask for an upload target.
Upload the file.
Reference the returned media ID.

And every platform has its own opinion about steps one through three.

Partial failures
"Publish everywhere" is never atomic. Three platforms succeed, one rate-limits you, and one rejects your image for reasons it declines to specify. It's a group project, and one member has gone quiet.
So now you need retry policies and a way to tell the user what actually happened without lying to them.

Formatting
Character limits, mentions, hashtags, markdown, media rendering—every platform supports roughly the same ideas and implements none of them the same way. The same post rarely looks identical in two places, and occasionally it shows up in one of them looking like a ransom note.

Token management
OAuth refresh tokens, app passwords, per-instance tokens—each with its own expiration rules and its own refresh flow. Authentication itself isn't the hard part. Supporting all of it at the same time, forever, is what quietly eats your week.

So... should you build it yourself?

If you're targeting one open network like Bluesky—absolutely, go native. The APIs are clean and you'll come out understanding the protocol properly.
Once you add several networks, plus scheduling, media, and retries, the math flips. Not because any single request is difficult, but because maintaining six integrations is not the reason any of us got into this.

Takeaway

AI didn't make social media publishing easier. It just made it impossible to ignore how fragmented the whole thing already was.
The hard part isn't generating text anymore. It's everything wrapped around it: auth, permissions, uploads, scheduling, retries, and a long tail of platform-specific edge cases.
Whether you handle that with direct integrations or hide it behind MCP is an architectural call. Knowing where the complexity actually lives is the part worth keeping.

I work on Publora, so that's the MCP server I know best—and it's open source (MIT) if you want to poke at it. But even if you never touch it, try wiring something up to Bluesky's AT Protocol, or stand up a tiny MCP server of your own. It's one of those weekend projects that makes all the trade-offs obvious by Sunday.
What are you using to connect your agents to the outside world these days?

Drafted with AI, then read start to finish by an actual human—which, given the topic, felt like the least I could do.

DEV Community: Eugeniya Ivanova