MCP server#2769

Adding an MCP server to Publer would allow access to structured data and enable better integration with external systems. It would also enable usage with tools like Claude Code, Cursor, and similar environments, improving automation and supporting more advanced use cases.

That and/or a connector in Claude Cowork

Until we launch our official MCP server, try this open-source MCP server from /alexkess and let me/him/us know what you think:

https://github.com/alexkess/publer-mcp-server

i will try that open-source MCP server. im using opencode for multi model agents and sometimes also use codex and antigravity too

Hello, any updates? much needed

Why an official Publer MCP server makes sense — from real production use, not a wishlist

I run my entire publishing pipeline through Claude Cowork, and I’ve been using the open-source server (alexkess/publer-mcp-server) for weeks. It works — which is the best proof of demand. But precisely because I use it in production, I can see exactly where a community build ends and an official server would win.

This isn’t a request for “access to data.” A read-only MCP is useless. It’s a request for full write-parity with the UI, so a human never has to go back into the panel.

The concrete gaps blocking full automation today

• No parity on the post schema. create_post only exposes text. There’s no separate TITLE field for YouTube and no first/pinned comment. So I can automate the entire draft — and still have to open the UI to set the YT title and the pinned comment. This one thing breaks the whole flow. An official server should expose the full schema: title, first/pinned comment, per-platform captions.
• Broken endpoints in the community build. delete_post returns a Rails 404 page, so I delete manually. get_me returns 404. A maintained, official server removes this class of problem.
• Media handling is unpredictable for an agent. A freshly uploaded video doesn’t appear in list_media until Publer finishes transcoding — and there’s no way to query transcode status. search misses names with non-ASCII characters and em-dashes.
• No real upload path for local files. Right now the only way to get a local export in is to upload it from a public/temp URL and then wait blindly. An official server should offer a proper upload handshake — initialize_upload → PUT to a presigned URL → finalize_upload returning a stable media_id, plus a transcode-status endpoint to poll. That would make pushing local video exports deterministic instead of a race.
• The API isn’t shaped for agents/LLMs. list_media without a filter returns ~66k characters and blows past tool limits. An official server should have pagination and field selection built with context windows in mind, not just raw dumps.
• Auth ergonomics. Manually juggling an API key + workspace_id (it’s easy to pass the user_id instead of the workspace_id and get a 401) is a real barrier. An OAuth connector removes it.

The principle

If it can be set in the post UI, it must be settable over MCP — including uploading media. Read-only helps no one. The value is that once a post is built and scheduled, the human never has to open the panel again.

Hi Publer team,

I have tested the official Publer MCP in real production workflows across a multi-workspace agency account, using Hermes, Claude/Codex, the MCP, and the REST API for deeper verification.

The beta is already useful. Dynamic workspace discovery, broad write coverage, analytics, agent-friendly tool descriptions, drafts by default, explicit publishing, batch confirmation, duplicate protection, and two-step deletion are all strong choices.

Here are our highest-priority improvements:

1. Require an explicit workspace for every write operation when an API key has access to multiple workspaces. The current fallback to the first accessible workspace creates a serious risk of posting to the wrong client account.

2. Add a complete get_publer_post tool. List responses omit labels, publication source, media IDs, alt text, comments, network options, and some timestamps. Agents need a full readback to verify exactly what was created. Labels can currently be written but are not returned with existing posts.

3. Make the media library actionable. A live list_publer_media call reported 2,371 items, but returned no usable media IDs, URLs, thumbnails, dimensions, or processing status. Stable IDs, metadata, thumbnails, processing state, and network compatibility are needed for reliable asset reuse.

4. Expose account connection and publishing status. list_publer_accounts should show whether each account is connected, can publish, requires reauthorization, or needs approval. We have seen disconnected accounts accept drafts that could not later be published.

5. Add typed per-network capabilities and a dry-run validator. post_type is a free string and network_options is an untyped object. Documentation search has also returned unrelated pages for detailed YouTube and Instagram questions. get_account_capabilities and validate_post would prevent invalid payloads before submission.

6. Clarify pagination and imported posts. A call with limit: 3 returned three posts but reported per_page: 20, with no has_more value or next cursor. Imported items should clearly return source: sync, editable: false, the native ID, and the public URL.

7. Add analytics metadata. Best-time results do not state the timezone or define the score, locale formatting is mixed, unavailable comparisons may appear as zero, and weekly buckets may begin before the requested period. Please include units, aggregation type, timezone, sample size, last sync, completeness, and null for unavailable data.

8. Extend update parity. update_publer_post currently covers text and title only. Drafts and scheduled posts should also support media, timing, comments, labels, and network-specific options. Unsupported fields should return explicit errors instead of being silently ignored.

9. Add client-supplied idempotency keys and per-item receipts. A completed asynchronous job has not always guaranteed that every requested draft exists, and some bulk errors have been associated with the wrong account. Each result should include client_ref, account, status, post ID, stable error code, and retryability.

10. Clarify plan eligibility and authentication. The feedback thread mentions Business and Enterprise, while the help article uses different eligibility wording. A clear access matrix would help. Authorization headers should be recommended over API keys in query URLs, which can leak into logs and history. Scoped, revocable OAuth would be ideal.

Additional ideas:

• prepare_batch followed by commit_batch, with a human-approval token;
• events for media.ready, post.failed, post.published, and account.reauth_required;
• analytics grouped by label, source, network, format, and campaign;
• short-link metadata with destination, UTM values, and click data;
• tools to add, reply to, or pin comments on published posts where supported;

• get_server_info with MCP version, schema version, and deprecations.

  The biggest next step is deterministic verification. An agent should be able to prove exactly what was created, on which account, with which media, comments, labels, options, and publishing status, without reopening the Publer interface.

MCP is a must have functionality. Working with Publer in a chat is the only reason why I subscribed it. Currently I am using the APIs by some helper scripts to make my agents able to work with Publer.

So… I’ve been testing the Publer MCP quite heavily over the last couple of days and it’s working really well for my workflow.
I’m using Hermes Agent as an editorial assistant. It reads my journal and editorial database, prepares short social posts, and now sends them to Publer. I have Bluesky, Threads, X and Instagram connected.
The biggest thing I’m missing right now is fuller support for Ideas. Creating Ideas through MCP works great, but the agent currently can’t reliably list/read/manage existing Ideas.
That makes Ideas almost perfect for this workflow, but not quite: I want the AI to create one canonical Idea, I edit it manually in Publer, and then use it for Bluesky / Threads / X. Ideally the MCP could later see which Ideas still exist, what I changed, whether they were already used, and avoid creating duplicates.
So the most useful additions for me would be:
– list Ideas
– read an Idea
– update an Idea
– delete an Idea
– ideally know whether an Idea has already been used/published
Everything else I tested — accounts, published posts, drafts and analytics, especially Instagram insights — has been surprisingly useful. This already looks like it could replace Buffer completely in my workflow.
Happy to keep testing and send more feedback if useful.

I have been using the Model Context Protocol (MCP) for the past two weeks to automate my workflow. Specifically, I set up a daily scheduler in ChatGPT that analyzes my LinkedIn performance data. Based on past performance and top-performing “winning” posts, it automatically drafts a new post targeted at my Ideal Customer Profile (ICP), generates a matching image, and schedules it to publish directly to my LinkedIn account.

Because ChatGPT uses MCP tools to continuously analyze what works best, my recent posts are highly optimized. This completely hands-off system has already driven a steady increase in views and engagement. Given the success of this LinkedIn automation, I am planning to expand this MCP-driven workflow to my other social media channels soon.

Update: Publer MCP is out of beta and available to everyone on the Business plan!

Connect Publer to ChatGPT, Claude, or another MCP-compatible AI assistant to plan, create, schedule, and analyze your social media through a conversation.

See what you can do: https://publer.com/blog/publer-mcp/