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.

Yep, we’re currently building the official one 💪

Why not building it as opensource right now for mcp? I believe it will make the progress faster and we can contribute too. If there is a bug many people can help to report the issue and fix it. It’s just mcp anyway I think it’s okay build it as an opensource at github. Plus having publer mcp also increase the publer exposure to public too