Give Claude Code a Social Media Presence in 15 Minutes

I gave Claude Code the ability to post to my company’s social accounts, and the setup took less time than writing this sentence took me. One CLI command, one API key, and the agent could list my connected channels, find an open slot on the calendar, and draft a scheduled post, all without me writing a line of integration code or filling out a single platform developer application.

That last part is the part people get wrong when they picture “AI agent posts to social media.” They picture OAuth apps, review queues, and a different SDK for every network. This tutorial skips all of that. By the end you will have Claude Code connected to PostSider over MCP, and you will have watched it draft and schedule a real post that a human still has to approve before it goes live.

Agents need a publishing surface, not a stack of platform APIs

An agent that has to authenticate separately with X, LinkedIn, Threads, and a dozen other networks spends more time managing credentials than doing the job you asked it to do. A single MCP server that already holds those connections gives the agent one contract instead of a dozen.

Every social platform has its own OAuth flow, its own developer application process, its own rate limits, and its own idea of what a valid post looks like. Wiring an agent directly to each one means building and maintaining that plumbing yourself, then keeping it working every time a platform changes its API. PostSider already did that work once, behind the dashboard you use to connect accounts. The MCP server sits on top of that and exposes it as a small set of typed tools an agent can call directly, over the same public API humans use through the app.

That is the actual value proposition here: you connect your channels to PostSider once, the normal way, in the dashboard. After that, giving an agent access to them is a config block, not a new integration project.

Setup takes one API key and one CLI command

Connecting Claude Code to PostSider needs two things: an API key from your PostSider account, and one entry in Claude Code’s MCP configuration pointing at the @postsider/mcp package on npm.

First, grab the key. In the PostSider dashboard, go to Settings, then Developers, then Public API, and generate a key. That key is POSTSIDER_API_KEY, and it is what authorizes every call the agent makes, so treat it like a password. There is also an optional POSTSIDER_API_URL variable if you are pointing at a non-default API host; leave it out and it defaults to https://api.postsider.com.

Second, register the server. As of the current Claude Code CLI, the documented way to add a local stdio server is claude mcp add, with the server’s own command and arguments separated from Claude’s own flags by a double dash. Run this from a terminal:

claude mcp add --env POSTSIDER_API_KEY=your-api-key --transport stdio postsider -- npx -y @postsider/mcp

That single line does three things: it names the server postsider, it sets POSTSIDER_API_KEY in the process environment, and it tells Claude Code to launch the server by running npx -y @postsider/mcp as a local subprocess talking over stdio, the standard input and output streams, rather than a network endpoint. No port to open, no URL to expose.

If you would rather manage the config as a file, project scoped MCP servers live in a .mcp.json file at your repo root, which Claude Code reads the same way. The equivalent block looks like this:

{
  "mcpServers": {
    "postsider": {
      "command": "npx",
      "args": ["-y", "@postsider/mcp"],
      "env": {
        "POSTSIDER_API_KEY": "your-api-key"
      }
    }
  }
}

Either path gets you the same result. Restart or reconnect the session and the agent has PostSider’s tools available. Under the hood, @postsider/mcp is a thin wrapper: every tool call turns into a request against PostSider’s versioned public REST API at /public/v1, the same API your own scripts or an SDK integration would call. The MCP server is not a separate product with its own logic; it is the agent-shaped door into the same house.

Worth checking once, before you trust it with anything: run /mcp inside a Claude Code session and confirm postsider shows as connected, or run claude mcp list from the shell. If the key is wrong or missing, the server still starts (it is just a local process), but every tool call fails with an authorization error instead of quietly doing nothing. That distinction matters when you are debugging why the agent claims it “can’t see any channels.”

The first run: list channels, find a slot, schedule a draft

You do not write tool calls by hand. You talk to Claude Code in plain language and it picks the right tool from the twelve the server exposes.

Start with a read. Ask something like “what social channels do I have connected in PostSider?” and the agent calls the list-channels tool, which returns your connected accounts and their platforms, drawn from the 30-plus networks PostSider supports. This is the step that matters more than it looks: the agent needs real channel identifiers before it can do anything else, and it gets them from a typed response instead of guessing at account names.

Next, ask it to plan. “Find me a free slot on LinkedIn sometime this week and draft a post about our new feature.” The agent calls the tool that finds the next open slot for that channel, based on your existing queue, then builds the post content and calls the create-post tool with a draft status. It might also call the tool that checks a post for missing fields first, catching an empty caption or a channel that needs media before you ever see the draft.

At this point nothing has gone anywhere near a real audience. The post sits in your PostSider queue exactly like one you wrote yourself, ready for you to open the dashboard, read it, and either approve it or tell the agent to try again. That review step is not an accident of how I described the demo. It is the default, and the next section is about why I built it that way.

Keeping it on a leash: draft-only by default

The single most important design choice in this setup is that the create-post tool takes a status, and draft is the one I tell people to use until they trust the agent’s judgment on their own accounts.

The same tool that creates a draft can also schedule a post for a future time or publish it immediately, depending on the status you pass. That flexibility is real, and so is the risk: an agent that can publish immediately can also publish something wrong immediately. Keeping the default at draft means every post the agent produces sits in a queue a human has to open before it becomes public. You get the speed of an agent doing the drafting and slot-finding, and you keep the one step that actually matters under a person’s control.

This is not a limitation you work around later. It is the shape of a system you can leave running unattended. An agent that drafts fifty posts overnight and waits for you to review them in the morning is useful. An agent that publishes fifty posts overnight is a support ticket, or worse, depending on what it decided to write at 3 a.m. Start every new connection in draft mode, watch a week of its output, and only loosen the leash on the specific channels and post types where the agent has earned it.

There is a second, quieter guardrail worth naming: every call the agent makes runs through the same public API and the same account activity your dashboard shows for a human user. Nothing about the MCP path is a side channel that skips logging. If a post shows up you did not expect, it traces back through the same queue and the same history a person’s action would, which is a much better starting point for debugging than “an AI did something to my account” with no record of what.

A tour of the 12 tools the agent can call

The server groups its tools into three shapes: reads that gather information, writes that create content, and management actions that change what already exists.

Group	Tools	What they do
Read	List channels, list channel groups, find next free slot, list posts, check post for missing fields, post analytics, channel analytics, notifications	Everything the agent needs to know before it acts: what accounts exist, when there is an open slot, what is already queued, and how past posts performed
Write	Upload media from URL, create or schedule or publish a post	The two actions that put new content into PostSider, one for media, one for the post itself with a status flag controlling draft, schedule, or publish
Manage	Update post status, delete post	Housekeeping on content that already exists, including moving a draft to scheduled once you have reviewed it

Eight of the twelve tools are reads, on purpose. A well-behaved agent checks before it acts: it lists channels before it schedules, it reads analytics before it claims something worked, it checks a post for missing fields before it hands you a draft with a blank caption. That read-heavy shape is what makes the agent’s output trustworthy enough to review quickly instead of re-checking everything by hand.

The write side is deliberately narrow. One tool handles media, one tool handles the post itself, and that single post tool covers draft, schedule, and immediate publish through one status argument rather than three separate endpoints. Fewer tools with clear jobs beats a sprawling API surface the agent has to reason about on every call.

The two analytics tools are easy to skip past and worth a second look. Post analytics and channel analytics both belong to the read group, which means an agent can close the loop on its own work: draft a post, wait for it to run, then check how it did, without you manually pulling numbers into the conversation. That is the difference between an agent that publishes content and an agent that can tell you which of its own posts actually worked.

If you want the deeper mechanics of how MCP tool discovery and calling actually work, what an MCP server is and how the schedule flow looks end to end cover that ground in more detail than fits here.

The fifteen-minute version

Get an API key from Settings, then Developers, then Public API. Run claude mcp add --env POSTSIDER_API_KEY=your-api-key --transport stdio postsider -- npx -y @postsider/mcp, or drop the equivalent block into .mcp.json. Ask the agent what channels are connected, ask it to find a slot and draft a post, then go look at what it wrote before anything ships. That is a working agent publishing setup, built from one config block instead of a stack of platform integrations.

Set it up against your own accounts by grabbing an API key at app.postsider.com/register, or read the full tool reference and quickstart at docs.postsider.com before you connect anything. The dashboard stays there for the moments you want to write a post yourself. The MCP bridge is there for the moments you would rather hand to an agent, with a human still holding the approve button.