The Model Context Protocol gives an assistant a typed set of tools instead of a browser and a prayer. For publishing, that turns “write me a caption” into something that can actually put the caption in a queue and tell you afterwards whether it went out.
Registering the connector
# Claude Code
claude mcp add --transport http wharf https://mcp.postwharf.com/mcp \
--header "Authorization: Bearer $POSTWHARF_KEY"
Any MCP client works the same way — the server speaks JSON-RPC over HTTP. The key is workspace-scoped, so a connector registered for one brand cannot publish to another. That property matters more with an agent than it does with a person: the blast radius of a mistake is bounded by the credential, not by the model's judgement.
What the tools do
Nineteen tools, and the useful shape is that they mirror the REST API rather than inventing an agent-specific surface:
- Read state: list channels, list the queue, list the drafts, read a single post, read the delivery events.
- Write: create a post now or scheduled, save it as a draft instead, edit a draft or anything still in the queue, publish a draft, cancel a queued post, attach media and describe an image.
- Check: whether the API is reachable and which networks it really publishes to, so an agent can tell you a delivery was simulated rather than sent.
Because reading the event feed is a tool, an agent can answer “did anything fail this week and why” without you opening the dashboard. That turns out to be the request people make most.
What to actually ask it
The requests that work well share a property: they involve fan-out or reconciliation, the two things that are tedious by hand.
“Draft three variants of this announcement, one per network, respecting each network's character limit. Queue them for Tuesday 9am and show me before you do.”
“Which posts failed in the last seven days, on which channels, and what was the error? Group by cause.”
“Cancel everything scheduled for Friday — the launch slipped.”
Requests that work badly are the ones where the model has to invent a fact: “post something about our new feature” produces a caption about a feature it does not know.
Where to keep a human
Two guardrails are worth having regardless of how much you trust the model.
Approve before first publish, not after. Scheduling is reversible — a queued post can be cancelled right up to its slot. Publishing is not. Ask the agent to schedule rather than publish, and the approval step costs nothing but a glance.
Keep the key scoped. One workspace per key. If an agent is drafting for a client brand, it should hold that client's key and nothing else. Rotate it from the dashboard the moment it has been pasted anywhere you would not paste a password.
An agent that can publish is an agent that can publish a mistake to thirty thousand people. The queue is the safety mechanism: everything lands in it first, and a cancelled post costs nothing.
The failure case worth designing for
Agents retry. If a tool call times out and the agent calls it again, you can get two posts. Idempotency is the fix, and it belongs on the server side — PostWharf's post creation is a single call that either creates one post with N deliveries or fails, and the queue claims delivery rows with FOR UPDATE SKIP LOCKED, so concurrent workers cannot publish the same delivery twice.
That is the property to ask any social posting MCP server about before you point an agent at it. Not “does it have an API” — “what happens if I call it twice”.
Setup instructions for other clients are on the Claude, ChatGPT, Cursor and n8n pages.
Common questions
Can Claude post to social media?
Yes, through a Model Context Protocol connector. Once it is registered, Claude can draft, queue, cancel and audit posts against a real workspace.
Is it safe to let an AI assistant publish on my behalf?
Keep a human approval step between drafting and publishing. The assistant is good at writing per-network variants and queuing them, and the decision to send should still be yours.
What happens if the agent retries and posts twice?
That is the failure case worth designing for. The fix belongs on the server: creating a post should be a single call that either creates one post or fails, so a repeated tool call cannot produce a duplicate.
PostWharf is priced per workspace rather than per connected channel, and every plan carries unlimited channels. See per-brand pricing.