How to post your release notes to X, LinkedIn, Threads and Bluesky from Claude Code

You shipped v2.3. The changelog is written, the tag is pushed, and now comes the part most solo developers skip: telling anyone. Writing four versions of the same announcement, one for each network's length limit and tone, then remembering to post them at a sensible hour, is exactly the kind of chore that never gets done on release day.

If you already work in Claude Code, you can hand it that chore. Claude Code can connect to remote tools over the Model Context Protocol (MCP), and several social media schedulers now run MCP servers. Once one is connected, Claude can read your CHANGELOG.md, write a post per network, and schedule them, without you leaving the terminal you shipped from.

This guide covers the whole loop: picking a scheduler, connecting it, the prompt that works, the per-network limits Claude needs to respect, and the guardrails that keep an agent from posting something you'd regret.

What you need

• Claude Code, installed and signed in.
• A scheduler with an MCP server that supports the networks you post to. Check that it uses each network's official API, and that it lets you limit what an agent may do (more on that below).
• Your social accounts connected inside that scheduler. You sign in to X, LinkedIn and the rest on the scheduler's side; Claude Code never sees those passwords.
• A changelog Claude can read. Any Markdown file works. Short, user-facing bullets ("Exports are 3x faster") make better posts than commit messages ("refactor export worker").

Step 1: Choose how much the agent is allowed to do

Before you connect anything, decide whether Claude may publish or only draft. This is the single most important setting in the whole workflow.

A good scheduler gives you levels like these:

Start with drafts. A language model will occasionally invent a feature, round a number the wrong way or tag the wrong account. A draft costs you one extra click; a wrong public post costs more.

If the server authenticates with an API key instead of a sign-in, remember that the key usually carries the full permissions of the person who created it. Keep it out of your repo and out of shared config.

Step 2: Connect the MCP server to Claude Code

Remote MCP servers are added with claude mcp add and the HTTP transport. Anthropic's Claude Code MCP documentation describes HTTP as the recommended option for remote servers and shows the general shape:

# Server that signs you in with OAuth in the browser
claude mcp add --transport http <name> <url>

# Server that takes an API key as a bearer token
claude mcp add --transport http <name> <url> \
  --header "Authorization: Bearer <your-key>"

Two details from the same docs are worth knowing:

1. Scope. By default a server is added at local scope: it loads only in the project where you ran the command. Add --scope user to make it available in every project, or --scope project to write it to a .mcp.json file your team can share. If you use a bearer token, don't put it in a project-scoped .mcp.json that gets committed.
2. Checking it worked. Run claude mcp list from your shell, or type /mcp inside a Claude Code session to see each server's status and finish any sign-in.

Then ask Claude something harmless first: "List my connected social accounts." If you get back your X handle, LinkedIn page and so on, the connection works.

Step 3: Write the prompt once, reuse it every release

The difference between generic AI posts and ones that sound like you is almost entirely in the prompt. Save something like this as a snippet, or as a Claude Code slash command if you release often:

Read CHANGELOG.md and find the section for the latest version.

Write launch posts for:
- X: a thread of 2-4 posts. First post says what shipped and why it
  matters to a user. No hashtags. Link only in the last post.
- LinkedIn: one post, plain language, short paragraphs, link to
  https://example.com/changelog as a link card.
- Threads: one post, conversational.
- Bluesky: one post.

Rules:
- Only mention changes that are in the changelog. Do not invent
  features, numbers or customer names.
- Stay inside each network's character limit.
- No emojis in the first line.

Create these as DRAFTS for Friday 09:00 in my time zone (Asia/Kolkata).
Show me every draft before you finish.

A few things make this prompt hold up:

• "Only mention changes that are in the changelog." This is your main defense against hallucinated features. Claude is reading a real file, so you can tell it to stay inside that file.
• An explicit time zone. "Friday 9am" means different things to you, the scheduler's server and the network. Say the zone, or give a full ISO 8601 time with an offset such as 2026-11-20T09:00:00+05:30.
• "Show me every draft." You want the text in your terminal so you can read it before you open the scheduler to approve.

Step 4: Respect each network's limits

Claude is good at writing to a length when you tell it the length. It is not reliably good at counting characters the way each network does, so build some margin in and let the scheduler's validation be the final check.

Practical rules that follow from this:

• Aim for about 250 characters on X. It leaves room for a link and an emoji without tripping the weighted count.
• Put the link where it helps. On X, a thread lets the first post carry the message and the last post carry the link. On LinkedIn, a link card is usually cleaner than a raw URL in the text.
• Don't reuse the X version on LinkedIn. LinkedIn gives you ten times the space; one or two short paragraphs explaining who the change helps read far better there than a squeezed 280-character line.

One cost to know about: X now prices API usage by consumption (see X API pricing), so schedulers often cap how many X posts you can send per day or month. A three-post thread uses three posts from that allowance.

Step 5: Review, approve, and check what went out

When Claude finishes, you should have one draft per network. Before approving:

1. Read every draft against the changelog. Anything that isn't in the changelog comes out.
2. Check the accounts. If you run more than one X account, make sure the draft is on the right one.
3. Check the time. Open the scheduler's calendar and confirm the posts sit where you expect, in your time zone.
4. Approve. Only now does anything become public.

After the posts go out, you can close the loop from the same terminal: "How did last Friday's release posts do?" If your scheduler exposes analytics over MCP, Claude can pull views and engagement per post, which is a quick way to learn which networks are worth writing longer versions for next time.

Guardrails worth setting up

Agents that post in public deserve a few more safety checks than agents that edit code.

• Never let a failed send retry blindly. If the connection to a network drops halfway through a send, the post may or may not be live. A scheduler that automatically retries can publish duplicates. Prefer one that marks the post as "check the account" instead.
• Keep the agent's key separate. Create a key, or a connected app, just for Claude Code so you can revoke it without touching anything else.
• Mind MCP output size. Claude Code warns when an MCP tool returns more than 10,000 tokens and caps output at 25,000 by default (docs). If you ask for "all my posts from this year," expect it to be truncated; ask for a date range instead.
• Follow each network's rules. Automation through official APIs is allowed; what you post still has to follow each platform's own policies, including disclosure rules for AI-generated media where they apply.

Which scheduler should you use?

Several schedulers now publish Claude Code setup guides for their MCP servers, including Postiz, Preflight and bundle.social. When comparing them, check four things:

1. Networks. Does it cover every network you post to, through the official API?
2. Permission levels. Can you give the agent drafts-only access?
3. Duplicate protection. What happens when a send fails halfway?
4. Pricing model. Per account, per channel, per post, or flat? Release posts across four networks add up fast on per-post X pricing.

Disclosure: I built Sendhour, a social media scheduler that has an MCP server for this exact workflow. It posts to TikTok, YouTube, Instagram, Threads, Bluesky, X and LinkedIn through each network's official API. Agents can connect with read-only, drafts-only or full-posting access, and a send that loses contact with a network midway is marked "Check account" rather than retried, so you don't get duplicates. Connecting it to Claude Code is one command, and the setup for other agents is in the API docs. Plans start at $29/month for 5 accounts. Pick whichever tool fits your networks and budget; the workflow above works the same with any of them.

claude mcp add --transport http sendhour https://sendhour.com/mcp --header "Authorization: Bearer sh_your_api_key"

Wrapping up

The point isn't to let an AI run your social accounts. It's to remove the friction between shipping something and saying so. With an MCP-connected scheduler, a release announcement becomes one saved prompt, one review pass and one click to approve. You'll do it every release instead of every third, and that consistency matters more than any single post.

Start small: connect a scheduler with drafts-only access, run the prompt on your next release, and edit what comes back. After a few releases you'll know whether the drafts are good enough to trust with more.