Posting to X (Twitter) with an MCP server

X is where AI-written social copy fails most visibly, and for a mechanical reason: models are bad at counting characters. Ask for “under 280” and you will reliably get 310, delivered with confidence.

That makes X a useful lens on what a social media MCP server needs to do beyond “send the post”. Everything below is about the gap between a model writing copy and copy that a platform will accept.

How posting to X through MCP actually works

1. 1
   Connect X once, through X

   The account is authorised through X’s own OAuth sign-in on the publishing service. An encrypted access token comes back and stays in the backend vault. No password, app registration or API tier to manage yourself.

2. 2
   Point your AI client at the MCP server

   A five-line JSON block for Claude Desktop or Cursor; a hosted URL for Claude.ai. Publishing tools appear in the client’s tool list, and X is one of the profiles they can target.

3. 3
   Ask for a post

   The model drafts, calls preflight_post to check the limit, fixes what is over, then calls create_post against your X profileId. You approve the write, and it comes back with the live URL.

Why preflight matters more on X than anywhere

LinkedIn gives you around 3,000 characters — nothing a model writes will hit it. X gives you 280, which every second draft exceeds.

Without a dry-run tool, the sequence is: model writes 310 characters, calls create, X rejects it, model apologises and rewrites. If the post was scheduled rather than immediate, that rejection happens at 9am on Tuesday with nobody watching.

preflight_post runs the same validation and publishes nothing. It reports the overflow per network, plus unconnected profiles, missing media and the credit cost. The model sees “34 characters over for twitter”, rewrites, and only then commits.

Do not cross-post the same paragraph

The clearest sign of an automated feed is a LinkedIn paragraph truncated into an X post. They are different rooms. LinkedIn rewards context and a first-person story; X punishes wind-up and rewards one claim you could quote.

The mechanism that fixes this is per-profile content: one instruction, different copy per destination, stored as separate posts.

{
  "content": "We shipped scheduled retries 🚀",
  "targetAccounts": [
    { "platform": "linkedin", "profileId": "lin_7741903",
      "content": "Failed posts used to need a human. From today they retry themselves — here is what we learned building it…" },
    { "platform": "twitter",  "profileId": "tw_1293847",
      "content": "Failed posts now retry themselves. No more Monday morning archaeology." }
  ],
  "scheduleDate": "2026-09-01",
  "scheduleTime": "10:00",
  "timezone": "Asia/Kolkata"
}

In practice you never write that JSON — you say “post this to both, but make the X version a single punchy line” and the model fills it in. The point is that the surface supports the distinction, so the model is not forced to choose one register for both. More on that in the cross-posting tool page.

One post per profile, and why it matters here

Targeting LinkedIn and X creates two independent records with their own ids and statuses. If X rejects yours for duplicate content while LinkedIn succeeds, you retry exactly one of them.

The alternative — one record with two destinations — makes retrying a gamble, because the safe action depends on partial state the agent has to reason about. Per-profile records remove the ambiguity, which is exactly what you want when the thing doing the retrying is a language model.

Prompts that work for X specifically

• Give a target, not a limit. “Aim for 200 characters” lands under 280 far more reliably than “stay under 280”, because it leaves room for the model’s bad estimate.
• Ask for one idea. “One claim, no list, no thread” prevents the summarising register that reads like a press release.
• Ban the tells. Rhetorical opening questions and “Here’s the thing:” are model defaults. Say so once and store it in your brand voice so you never say it again.
• Name the timezone. Scheduling defaults to UTC — “9am IST”, never just “9am”.

When a calendar beats a chat window

Drafting in conversation is excellent. Seeing a week of X posts laid out next to everything else is not something a chat window does well.

Both views read the same queue, so a post drafted in Claude appears in the X scheduler and can be edited or moved there. Use the agent for the writing and the calendar for the seeing — the split costs nothing, because it is one queue underneath.