How to Give Claude the Ability to Post to Social Media

An MCP server for social media publishing lets AI agents draft, schedule, and publish posts to networks like X, LinkedIn, TikTok, and Instagram without exposing OAuth tokens or per-platform delivery logic to the agent itself. The Model Context Protocol (MCP) standardizes how an agent discovers and calls external tools; a unified publishing API behind that protocol gives the agent a single tool worth calling.

This is useful for Claude Desktop and Cursor users whose AI assistant should actually publish drafts, for AI content products embedding a publish step in their workflow, and for autonomous agents that schedule and post on a user's behalf. Teams that want the same publish surface without the agent layer can read the multi-platform publishing guide instead.

Why can't AI agents already post to social media?

The hard part is not writing the post. A modern LLM can produce a publication-ready X thread in seconds and tune it to nine networks in a minute. The hard part is finishing the workflow. Three things sit between draft and published that do not belong to the model.

• Authorizing the user's social account. OAuth is a browser-mediated, user-initiated handshake. The agent cannot grant access on the user's behalf, and any pattern that lets it try is a security incident in the making.
• Translating one piece of content into nine platform shapes. Instagram requires Business or Creator accounts, TikTok gates publishing scopes behind app review, and LinkedIn wants different payloads for text, image, and document posts.
• Reporting delivery back to the agent. Publishing is asynchronous—the platform accepts the request, then succeeds, fails with a platform-specific error, or sits in a processing state. The agent needs to know which, without pretending failed posts succeeded.

None of this is a model failure. The work has to live somewhere, and that somewhere should not be inside the tool-use loop.

What does MCP standardize, and what does it leave to the server?

The Model Context Protocol standardizes how an agent discovers and calls external tools. Claude Desktop, Cursor, Cline, and Continue.dev all speak it today. MCP does not solve the authentication geometry behind those tools. If the tool definition is “post to TikTok,” MCP does not say where the OAuth token comes from, how it gets refreshed, or what happens when the user revokes scopes. That work lives in the MCP server.

UniPost's MCP server sits in exactly that gap. The flow is Agent → MCP → UniPost API → 9 social platforms. The agent calls a flat unipost_* tool, UniPost handles the per-platform shape, and OAuth tokens stay on the UniPost side—bound to the account id the user created out of band.

How do I wire Claude into UniPost?

Use UniPost's hosted Streamable HTTP MCP endpoint in Claude Desktop. That keeps Claude on the current tool surface without running a local stdio proxy.

{
  "mcpServers": {
    "unipost": {
      "url": "https://mcp.unipost.dev/mcp",
      "headers": {
        "Authorization": "Bearer up_live_..."
      }
    }
  }
}

Restart Claude Desktop and the unipost_list_accounts, unipost_create_draft, unipost_publish_draft, unipost_create_connect_session, and other current unipost_* tools become available in the next conversation. Cursor, Cline, and Continue.dev have their own MCP config files; use the same URL and authorization header in their MCP server entry.

What does an AI publish workflow look like in practice?

With the server connected, a publish task looks like a normal Claude turn—except the side effects are real.

You: Draft a launch announcement for our new analytics dashboard
     and publish it to X and LinkedIn.

Claude: I'll list your connected accounts first to pick the right ones.
        [tool: unipost_list_accounts]
        → sa_x_kCqz        (account: @yourhandle)
        → sa_linkedin_4dQp (account: Your Company)

        Now I'll create a draft you can review.
        [tool: unipost_create_draft
          platform_posts=[
            { account_id: "sa_x_kCqz",        caption: "..." },
            { account_id: "sa_linkedin_4dQp", caption: "..." }
          ]]
        → draft_id: dr_8H2k

        Want to publish, or edit captions first?

You: Publish.

Claude: [tool: unipost_publish_draft id="dr_8H2k"]
        ✓ Published to X:        https://x.com/yourhandle/status/...
        ✓ Published to LinkedIn: https://www.linkedin.com/feed/update/...

The agent saw three tool calls. The user saw a single confirmation step. Under the hood, unipost_create_draft creates a draft with POST /v1/posts using status: "draft" and two platform_posts[] entries. unipost_publish_draft then publishes that draft through POST /v1/posts/:post_id/publish, where UniPost dispatches the per-platform delivery to X and LinkedIn behind the scenes.

How should AI agents handle OAuth?

They should not. The account id an agent uses (sa_x_kCqz above) is created earlier through a UniPost hosted Connect Session, and that step belongs to the user, not the agent. Your app—or even a one-time CLI run—opens the session, the user clicks through in a browser, and UniPost exposes the completed account as completed_social_account_id (managed_account_id for hosted Connect callers). That is the id the agent uses from that point on.

curl -X POST "https://api.unipost.dev/v1/connect/sessions" \
  -H "Authorization: Bearer $UNIPOST_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "platform": "twitter",
    "external_user_id": "user_123",
    "allow_quickstart_creds": true,
    "return_url": "https://yourapp.com/connected"
  }'

# Response → send the user to the returned `url`.
# After completion, read `completed_social_account_id` (or `managed_account_id`)
# from the session response and give that account id to the agent.

Why route OAuth through a hosted URL instead of letting the agent collect credentials? Because the agent is not authorized to grant access on a user's behalf, and any architecture that lets it try will eventually leak tokens, post to the wrong account, or fail a Meta App Review. The MCP server can list, draft, publish, schedule, and pull analytics. Authorizing a new account stays a deliberate, browser-mediated, user-driven step—by design.

What kinds of agents can I build with this?

• Draft-and-publish agents: Claude composes, the user confirms in one turn, the post ships.
• Scheduled content agents: a daily routine drafts and queues posts to the right accounts without anyone watching.
• Reply-to-comment agents: pair the MCP publishing tools with direct Inbox API calls, or your own MCP wrapper, so an agent can read supported DMs and comments and draft replies under the same authorization model.
• Multi-account broadcast from one prompt: same intent, per-platform variants, one tool call.

Build the integrations directly or use the MCP server?

Most of the cost of giving an AI agent publishing powers is not the tool definition. It is the surrounding work—OAuth, refresh tokens, media specs, delivery status, and webhooks—that you would otherwise rebuild for every platform you add.

FAQ