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.

To clarify, the Publer MCP Server requires an API key, and API access is available only on the Business and Enterprise plans.

Therefore, MCP will not be available on the Free plan and will be a Business and Enterprise feature.

I can’t access it - must not be a Top ;)

Everything that didn’t work — testing the Publer REST API directly.

I’ve been testing the public API (not the community MCP) to build a content pipeline through Claude. Account: Business trial, workspace with Instagram + LinkedIn connected. Here’s what broke, in order of severity:

1. Carousel posts are completely broken via the API
   POST /posts/schedule with “type”: “carousel” on the Instagram network fails every single time with: “undefined method ‘first’ for nil”.
   This is a raw Ruby exception, not a validation error. Tested 5 variations to rule out my own mistake: caption vs alt_text on media items, isolated single-network vs combined with LinkedIn in the same bulk call, media uploaded with in_library: true vs default, and a completely fresh date. Identical error every time. I can add multiple images to a post fine through the web UI — so it’s not an account/permissions issue, it’s specific to the public API’s carousel path.

2. No way to add media to an existing post (so no create-then-edit workaround either)
   Since direct carousel creation fails, I tried creating a single-photo post and then PUT /posts/:id with a media array containing 2 items, hoping to replicate what the UI does when you add a second image while editing. The update went through with no error, but the media array was silently left untouched — the second image was never added. The docs for this endpoint only mention text and title as updatable fields, so this tracks, but it means there’s currently no API path at all to a multi-photo Instagram post.

3. Story documentation is wrong / incomplete
   The Reels/Shorts/Stories doc page’s example implies “type”: “story” is a valid value for networks.instagram.type. In practice this returns “Post type is not valid”. The actual working structure is “type”: “photo” with a nested “details”: {“type”: “story”}. Would be great to fix the example in the docs — cost me a failed attempt to figure out.

4. Job status errors reference accounts that aren’t even part of that post
   When a bulk request has multiple posts[] entries targeting different accounts, GET /job_status/{job_id} sometimes returns failures like “composer is in a bad state… missing social network params” attributed to an account that isn’t in that specific post’s accounts array at all (e.g. a LinkedIn error on a post that only targets an Instagram account). This happened consistently across several of my test bulks. It looks like an indexing bug in how failures get matched back to posts — makes debugging real failures much harder since you can’t trust which account an error is actually about.

5. LinkedIn mentions don’t resolve via plain text or URN syntax
   Typing @Company Name in the text just stays as plain text on publish (expected, that’s a UI-autocomplete thing). I also tried the URN-embedding syntax @{urn:li:organization:ID|Display Name} that’s documented for a similar product — Publer’s API strips the braces and display name and stores it as literal visible text @urn:li:organization:3282045. If Publer’s API does support a structured mention format, it’s not documented anywhere I could find, and this syntax isn’t it.

6. Instagram photo tagging (the dot-tag-people feature) has zero API documentation
   Found nothing in the API reference for this — only a help-center article describing the UI flow. I guessed a field shape based on the UI description (“user_tags”: [{“username”: “…”, “x”: 0.5, “y”: 0.5}] on a media item) and it was accepted and actually worked, but that was a guess, not something I could’ve found in the docs. Would be great to have this documented since it’s a real, working feature.

7. Feature wish: “Share to Story” from an existing post, with text + link sticker
   Right now the only way to get content into a Story is uploading fresh media with “details”: {“type”: “story”} — there’s no way to actually share an existing post to Story (the “repost with a ‘view post’ tap-through” behavior Instagram itself has natively), and no link/link_sticker field to add a clickable link on top. Checked and this isn’t available in the web UI either, so this reads as a genuine feature gap rather than an API-only limitation. Would love to see: (a) a way to reference an existing post ID when creating a Story so it renders as a repost, and (b) a link_sticker field with a URL for Stories — this would make Stories usable for driving traffic (e.g. “new blog post” stories linking out), which right now they can’t do at all through Publer.

Hi Sara,

Thank you for taking the time to test everything in detail.

This is very helpful. I’ll forward all of these points to our team so they can review the API issues

Would love one for analytics and planning purposes

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.