Social Media Automation Over MCP, Without Losing the Review Step

You can describe a week of content in one sentence. Turning that sentence into scheduled posts takes forty minutes of tab switching, character counting and timezone arithmetic. The assistant open in your other window could do all of it, except it cannot reach your scheduler, so it writes you a tidy list and you become the API.

The Model Context Protocol is the wiring that closes that gap. Here is what it actually is, how to connect a scheduler to it, what to ask for once it works, and where to keep a human in the loop so an automated queue never quietly becomes an unsupervised one.

What MCP actually is

MCP is an open standard that lets AI assistants discover and call external tools. A server describes the actions it offers and the shape of the arguments each one takes. A client, which is your assistant, reads that description and can then call those actions mid-conversation. That is the whole idea, and its ordinariness is the point.

The value is not magic, it is that the description is standardized. Before MCP, every assistant needed a bespoke plugin for every tool, and every tool needed a bespoke plugin for every assistant, so most integrations were never built. Now one server works with any compatible client: Claude Desktop, Claude Code, Cursor, ChatGPT, Codex, and open agents such as OpenClaw and Hermes.

Two consequences matter for social media. The server, not the model, decides which actions exist at all, so the boundary of what an assistant can do is something you configure rather than something you hope for. And every call is an ordinary authenticated API call made with your credentials, which means it obeys the same permissions and leaves the same trail as anything else you run.

Connecting a scheduler in one command

postqueen ships an MCP server inside the app, so there is nothing extra to install or host. You need one API key from Settings, then Developers, and one line in your client.

# Claude Code: one command
claude mcp add --transport http postqueen \
  https://api.postqueen.ai/mcp/YOUR_API_KEY

Clients that take a JSON block instead of a command, such as Claude Desktop and Cursor, accept the same URL:

{
  "mcpServers": {
    "postqueen": {
      "url": "https://api.postqueen.ai/mcp/YOUR_API_KEY"
    }
  }
}

Putting the key in the URL is the fastest path and it is fine on your own machine. It is a poor idea anywhere you might screenshot, paste into an issue, or commit by accident, because a URL does not look like a secret and people treat it accordingly. For those cases, send the key as a header, or use the OAuth endpoint, which grants scoped access with mcp:read and mcp:write instead of handing over a key that can do everything.

# Key as a header instead of in the URL
https://api.postqueen.ai/mcp
Authorization: Bearer YOUR_API_KEY
 
# OAuth capable clients: scoped access
https://api.postqueen.ai/mcp-oauth
# scopes: mcp:read, mcp:write

Once connected, the assistant can see your channels, draft and schedule posts, choose publish times, attach media, list what is queued and pull analytics back out. Where your plan includes AI image or video generation, it can produce the visual inside the same conversation rather than sending you to another tool and back.

What to actually ask for

The difference between a useful session and an annoying one is specificity, exactly as it is with a human contractor. An assistant with tools does not need you to explain the mechanics. It does need the constraints that are currently living in your head and nowhere else.

• Name the channels. Telling it to post everywhere invites a guess about which of your connected accounts counts as everywhere.
• Give the timezone, not just the hour. Nine in the morning means nothing to a model building a UTC timestamp, so it will pick something.
• Say queue or publish. This is the most important word in the prompt, and it should almost always be queue.
• Ask for the idea rewritten per network, not the same text repeated. Otherwise you get one paragraph pasted five times, which reads exactly like one paragraph pasted five times.
• Ask it to list what it created when it finishes. That is one extra tool call and it is your receipt.

A prompt that works: draft five posts about the 2.4 release, one per weekday next week at 9 AM America/New_York, queued rather than published, for X, LinkedIn and Mastodon, rewritten for each network, then list what you queued. It is a boring sentence. Boring is the entire point, because every clause in it is a decision the model no longer has to invent.

Review gates that survive a bad day

Giving a model write access to your public voice is a real decision, and worth treating as one. It is also manageable, because the failure modes are known and the gates are cheap.

Queue, never publish now

This is the whole safety model in four words. A queued post sits in a calendar where you can read it, fix it or delete it. A published post is on five networks and in somebody's screenshot folder. Schedule far enough ahead that a human passes the calendar before the scheduler fires, and almost every mistake downgrades from an incident to a non-event.

Queue, do not publish. A scheduled post is a draft with a deadline, and a deadline you can still cancel.

Read before write

Start with read-only access while you learn what the assistant does with your prompts, which is rarely what you predicted in week one. On OAuth capable clients that means granting mcp:read and withholding mcp:write until the drafts stop surprising you. This costs you one afternoon of copying text by hand and buys you an accurate mental model of a tool you are about to trust.

One key per agent, revoked without ceremony

Separate keys per assistant or per machine cost nothing and mean revoking one does not break the others. Revocation is the real control here: it is instant, it needs no cooperation from the agent, and it works on a Friday evening when the laptop is already gone and nobody wants to debug anything.

The assistant never touches your accounts

This is worth being precise about, because it is the part people fear most. Passwords and network tokens stay inside the scheduler. The assistant holds a scheduler key and asks the scheduler to act on its behalf. The blast radius of that key is your queue, not your identity, and that distinction is what makes the whole arrangement reasonable rather than reckless.

Where MCP is the wrong tool

Some jobs should not be a conversation, and pretending otherwise is how automation projects get abandoned in month two.

• Deterministic recurring work. If the job is to take these rows every Monday and queue them, use cron, a CLI script or an n8n flow. A model doing it weekly will eventually do it slightly differently, and that variance buys you nothing.
• Bulk imports. Two hundred posts belong in a file and one CLI call, not in a context window where they compete for attention with your instructions.
• Work where being off by one matters. Dates, timezones and phrases like the third Tuesday are exactly where a two line script is strongest and a language model is weakest.
• Brand voice you have never written down. An assistant matches the voice in your prompt, not the voice in your head, so if the guidelines are unwritten then review is not optional.

The division of labor that holds up is the obvious one. Let the assistant do the part that is genuinely language work: drafting, rewriting per network, summarizing what went out and what it did. Let deterministic tools own the clock and the repetition. postqueen exposes both surfaces from the same account, an MCP server and a CLI, so picking one for a given task is not a migration or a commitment. It is just choosing the right tool that afternoon, and changing your mind next week costs nothing.