Post to Bluesky from Claude or ChatGPT with an MCP server

Is there an official Bluesky MCP server?

No. Bluesky’s own GitHub organisation has no MCP server. Bluesky supports OAuth for apps since September 2024 and asks new projects to prefer it, while still recommending app passwords for bots and command-line tools. The community servers all sign in with an app password, and so does Hub.

Read on 1 October 2026 from each project’s own page. Descriptions of other servers are their own claims; Mellow has not tested them.

Sources: Bluesky’s OAuth announcement and its client guide, read on 1 October 2026.

What Bluesky account do I need?

Any Bluesky account. Hub connects Bluesky with your handle and an app password rather than a sign-in screen, so an agent cannot complete this step alone.

Create the app password in Bluesky under Settings → Privacy and security → App passwords, give it a name you will recognise, and leave direct-message access off: Hub does not need it. Bluesky shows the password once, so paste it straight into Hub’s connect form with your full handle, such as name.bsky.social. Never use your account password. You can revoke an app password in the same place at any time without changing your password, and Hub’s connection stops with it.

1. Open Accounts in Hub and choose Bluesky, or ask the assistant to call connect_channel with platform set to bluesky. That tool only returns a link and an instruction for a person. It needs the channels:connect permission.
2. Enter the details Hub asks for yourself. An assistant cannot do this step for you.
3. Tell the assistant you are done. It calls list_channels with refresh: true and uses the returned channel ID, which begins with spc_. A username is not a substitute for that ID.

Connect Claude, ChatGPT, Cursor or another MCP client

Every client uses the same server URL, https://www.mellow.world/mcp, over Streamable HTTP. A client signs in with OAuth 2.1 (dynamic client registration and PKCE) or sends an owner-created Hub API key as a Bearer token. Menus change between client versions, so the official guides linked below describe the current screens. The last column says only what Mellow itself has tested, on any network.

1. Add the server in your client and select Connect. Sign in to Mellow if asked. Hub’s consent screen names the app that is asking.
2. Choose the permissions the task needs (below), select your Bluesky channel, choose review or autopilot, a daily ceiling and an expiry, then approve.
3. Back in the client, run the read-only check from the prompts below. Confirm the profile, the mode and the Bluesky channel ID. Agents shows the grant’s permissions, channels and expiry.
4. If a client cannot complete OAuth, create a key in Agents and set it as the client’s Authorization: Bearer header, from its secret settings or an environment variable. Never paste a key into a chat.

Which permissions to approve

The consent screen arrives with every permission the assistant asked for already ticked, except spending AI credits. Untick anything it should not have.

What you delegate, and how to take it back

Hub treats an assistant’s access as a delegation you give once, with limits: the permissions, the channels (the ones you select, or explicitly all), review or autopilot, a daily ceiling of 1 to 1,000 posts (50 by default) and an expiry of 1, 7 or 30 days (30 by default). Autopilot is the default: the assistant publishes on its own within those limits. Choose review and each post waits for you to approve it in Hub. A key or a connected app cannot approve its own post.

Hub records the posts an assistant creates or has refused, approvals, reschedules, cancellations and connection attempts in a journal you read in Agents. Revoking a key or a connected app takes effect on its next request. Publishing always needs an idempotency key, so a retried request cannot publish twice.

Bluesky rules Hub checks before anything is sent

This table is generated from the registry that validate_post enforces, the same one behind the rules for every network. These are Hub’s input rules; Bluesky still judges the media itself when it fetches it.

Bluesky counts graphemes, the characters as you see them, so an emoji counts once however it is built; the limit is 300 (Bluesky documentation). Bluesky’s app has recently allowed more than Hub sends: ten images since June 2026 and videos of up to ten minutes since August 2026. Hub’s checks follow Bluesky’s API documentation, which still gives four images.

When validate_post refuses the post

Read ok, issues and notes in the result. The check publishes nothing and reports every problem at once, each with its field and, for a network rule, its channel. Fix them together and validate again.

Other refusals concern the request or the grant: schedule_in_past (use a future time with a UTC offset), insufficient_scope (approve a delegation with the missing permission), channel_out_of_scope (the channel is not in the grant), and at creation daily_limit_reached and idempotency_key_reused. A passing check is not proof of publication: Bluesky can still refuse the media or the account. The free post checker runs the same input rules on a draft before you connect anything.

Prompts you can paste

Replace the bracketed parts. Each prompt names the tools to call, so the assistant does not have to guess the order.

Use only Mellow Hub. Call whoami, then list_channels, then list_platforms.
Tell me my Bluesky channel ID, whether this connection is in review or
autopilot mode, how many posts it may still create today, and Bluesky's
rules. Do not create anything.

Use Mellow Hub. Post this to my Bluesky, Threads and X channels:
[your post]

If validate_post says it is too long for any of them, write a shorter
version for that channel only, put it in perChannel, show me all versions
and wait for my yes. Then create_post once with idempotencyKey
"short-[short-name]-1" and get_post. Report each target separately.

Media has to be reachable at a public https URL when Bluesky fetches it. An agent that can make HTTP requests, such as Claude Code or a script of your own, can instead call request_upload_url, send a local file with PUT to the returned uploadUrl and use the returned mediaUrl. An assistant that only has Hub’s tools cannot send file bytes itself.

Publish once, then read the Bluesky result

create_post is the step that publishes or schedules. It needs an idempotencyKey of 8 to 120 letters, digits or the characters . _ : -, stable for this post. If the response is lost or times out, send the same request with the same key: Hub returns the original post instead of making a second one. Reusing a key for different content is refused.

Under a review-mode grant the post comes back as pending_review and waits until you approve it, signed in, in Hub. Under autopilot it goes out at scheduledAt, or immediately without it. Always write scheduledAt with Z or an explicit UTC offset.

Then call get_post and read the Bluesky entry in targets, not only the post’s status. publishing means Bluesky has not reported a result yet; published comes with the post’s link; failed comes with the network’s message. In a post to several networks each target settles on its own and the post can end partial: republish only the failed channel, with a new key. Once Bluesky has published a post, Hub cannot edit or delete it; cancel_post works only before it goes out.

Each destination counts once against your plan: one post to Bluesky and two other networks is three publications. Validating, drafting and connecting work without a plan; publishing needs an active one. See plans.

What Mellow has tested with Bluesky

On 1 October 2026 at 07:42 UTC Hub published its first Bluesky post in production: a text post sent from the web cabinet, public on Bluesky ten seconds later.

On 2 October 2026, ChatGPT, with Hub added as a developer-mode app on the web, posted to a test account’s Bluesky channel through the MCP server. A post it published went out 11 seconds after the request, at 09:46 UTC. A post it scheduled for 03:00 UTC on 3 October went out on its own at 03:01. A 365-character text was refused by validate_post before anything was sent. See the ChatGPT guide. Hub’s connect form, its grapheme count and its checks are also covered by automated tests.

Questions

Related

• Threads MCP guide and X MCP guide: the other short-post networks.
• Character counter with Bluesky’s grapheme count.
• Publish to social media with an MCP server: the workflow for every network.
• Before an AI agent posts: an MCP checklist.
• API and MCP reference and rules for every network.
• Plans: each destination counts once against the monthly publications.