DEV Community: PipepostDev

Pipepost v0.9.0 — Substack publishing + the agent-loop transcript

PipepostDev — Thu, 16 Apr 2026 19:04:55 +0000

Pipepost v0.9.0 — Substack publishing + the agent-loop transcript

You can now publish to Substack from Claude Code. That makes 6 CMS platforms in a single MCP server: Dev.to, Ghost, Hashnode, WordPress, Medium, and Substack.

But the more interesting part of v0.9.0 isn't a new platform. It's a transcript showing what an agent-loop publishing pipeline actually looks like.

What an agent loop replaces

If you publish to multiple platforms today, the manual flow is roughly:

Open Dev.to, paste, format, tag, save draft
Open Ghost admin, paste, format, set canonical URL, save draft
Open Hashnode, paste, format, set canonical URL, save draft
Open WordPress, paste, format, set canonical URL, save draft
Open Substack, paste, format, save draft
Open three SEO tools — one for scoring, one for meta tags, one for schema
Open Twitter compose, write a thread of 4 tweets
Open LinkedIn, write a professional version of the same post
Open Bluesky, write a 287-character version
Open Bing Webmaster Tools, paste the URL, click submit

Realistic time: 45 to 90 minutes of context switching.

The agent-loop version of that flow is one prompt:

Take this draft, audit it, score it for SEO, fix any issues, cross-publish to Dev.to, Ghost, Hashnode, WordPress and Substack as drafts with the Dev.to URL as the canonical, generate Twitter + LinkedIn + Bluesky posts, and submit the Dev.to URL to IndexNow.

Claude Code chains the calls, threads the canonical URL between them, prints the output, and asks if you want to flip the drafts to published.

The full annotated transcript is in the repo: docs/demo/agent-loop.md.

The Substack piece

Substack does not have a public API. The publish tool now talks to Substack's reverse-engineered endpoints:

POST /api/v1/drafts to create
POST /api/v1/drafts/{id}/publish to publish
Cookie auth via connect.sid (DevTools → Application → Cookies → substack.com)
Markdown converted to ProseMirror documents (paragraphs, headings, code blocks, blockquotes, bullet lists, inline bold/italic/code/links)
user_id resolved from /api/v1/user/profile/self on first publish, then cached in ~/.pipepost/config.json

Setup:

npx pipepost-mcp init
# then in Claude Code:
# setup platform=substack connect_sid=<cookie> publication_url=https://you.substack.com
# publish platform=substack title="..." content="..." status=draft

What v0.9.0 ships with

30 MCP tools
6 CMS publish targets (Dev.to, Ghost, Hashnode, WordPress, Medium, Substack)
4 direct social broadcast targets (Bluesky, Mastodon, LinkedIn, X)
4 SEO tools (scoring, meta, schema, IndexNow)
4 draft tools (save, list, get, delete)
4 Bluesky listening + reply tools
Cover image search (Unsplash)
Frontmatter generator for 7 SSGs
Content audit + link checker
Repurpose + generate-social-posts
Unified analytics across all configured platforms
446 tests, MIT licensed, no telemetry

Install:

npx pipepost-mcp init

Read the transcript: docs/demo/agent-loop.md

What an MCP server for content publishing actually needs to do

PipepostDev — Thu, 16 Apr 2026 17:03:24 +0000

An MCP server for content publishing turns your AI assistant into a publishing pipeline. You write a markdown draft, the assistant calls the server's tools, and the post lands on Dev.to, Hashnode, Ghost, WordPress, Medium — plus broadcasts to Bluesky, Mastodon, LinkedIn, and X — without you leaving the conversation.

This post is the design rationale. What does a content-publishing MCP server actually need to do, why does the MCP architecture fit this problem better than a CLI or a SaaS, and what separates a good one from a thin API wrapper.

What "content publishing" means in practice

A complete content-publishing pipeline does five things:

Drafts — write or edit markdown locally, with frontmatter for metadata
Scores — SEO-check the post (readability, headings, keyword density, meta description) before it goes anywhere
Enriches — generate JSON-LD schema, canonical URLs, Open Graph tags
Publishes — send the post to one or more CMS platforms with the right field mapping per platform
Broadcasts — generate platform-specific social copy and post it to whichever networks you care about

A CLI can do all five but you have to remember which command flag does what. A SaaS can do all five but it owns your drafts and your publishing history. An MCP server lets your AI assistant do all five using natural language while keeping your drafts as files you own.

Why MCP fits this problem

Content publishing is where MCP shines because every step is a discrete tool call with clear inputs and outputs.

"Score this post for SEO" → seo_score returns 0-100 + recommendations
"Generate JSON-LD for it" → generate_schema returns the markup
"Publish to dev.to as a draft" → devto_post returns the draft URL
"Now post a thread about it on Bluesky" → bluesky_post returns the post URL

Each tool is independently testable. Each tool returns structured data the assistant can reason about. The assistant can chain them in whatever order makes sense ("score it, fix anything below 80, publish, then broadcast"), and the user never has to remember command-line syntax.

This is also why MCP beats Zapier or Make for content workflows specifically. Zapier triggers are event-based; you set up a flow and it runs unattended. Content publishing is the opposite — the human (or the assistant on the human's behalf) decides post by post what to do. MCP is the right shape for the latter.

What separates a good content-publishing MCP server from a thin wrapper

If your "MCP server for content publishing" is one tool that takes {platform, content} and POSTs to whichever API, you have a thin wrapper. That's not enough.

The bar:

Per-platform field handling. Dev.to wants tags (max 4, no spaces), canonical_url, series, cover_image (1000x420). Hashnode wants tags as full objects with slugs, a coverImageOptions field, and publicationId. WordPress wants status, categories (numeric IDs not names), and an authentication header that's distinct from the standard Bearer pattern. Each platform has its own quirks. A good MCP server hides them.

Auth handling that actually works. Different platforms have different auth models: API keys (Dev.to, Hashnode), application passwords (WordPress), Admin API keys with JWT signing (Ghost), OAuth 2.0 (LinkedIn, Medium), OAuth 1.0a (X). A good server stores credentials safely and surfaces clear errors when they're wrong or expired.

Canonical URLs handled by default. When you cross-post to four platforms, you have one canonical URL — your own blog. Every other platform should point its canonical_url field at the original. Good MCP servers wire this automatically; bad ones leave you to figure it out per platform.

SEO scoring as a first-class tool, not an afterthought. "Did the post hit a reasonable readability score" is a five-second check that catches drafts that aren't ready. A content-publishing MCP server that doesn't include SEO scoring is treating publishing as a destination instead of a quality gate.

Schema.org JSON-LD generated from the markdown. Search engines want structured data. Generating Article-type JSON-LD from a markdown post is mechanical: title, description, date, author, word count. A good MCP server emits it; you copy it into your blog template once and you're done.

Broadcast tools alongside publish tools. Content gets seen because someone shared it. A content-publishing MCP server should generate platform-specific social copy and let the assistant post it to Bluesky/Mastodon/LinkedIn/X in the same conversation as the publish step.

The reference implementation

Pipepost is the open-source MCP server that hits all of those criteria today. Five CMS clients (Dev.to, Hashnode, Ghost, WordPress, Medium), four social broadcast tools (Bluesky, Mastodon, LinkedIn, X), SEO scoring, schema.org generation, canonical URL handling, link checking, draft management, content audit, content repurposing into social copy. 30 tools total, 414 tests, runs over stdio in any MCP client.

npm install -g pipepost-mcp

Then add to your MCP client config:

{
  "mcpServers": {
    "pipepost": {
      "command": "npx",
      "args": ["-y", "pipepost-mcp"]
    }
  }
}

When a content-publishing MCP server is the wrong tool

If your publishing workflow is one platform, no SEO requirements, and the official web editor works fine, you don't need an MCP server. Open the web app, paste, publish.

If your team has a content calendar, a copywriter, an editor, a designer reviewing covers — you need a CMS plus a workflow tool, not an MCP server. MCP serves the dev-and-marketer-of-one model where the same person is writing, editing, publishing, and promoting.

For everyone in between (technical founders, indie devs, dev-rel teams of one), an MCP server collapses the publishing step into a sentence. That's the entire pitch.

Source on GitHub. npm. Available on the MCP Registry.

Publish to Dev.to from Claude Code in one MCP call

PipepostDev — Thu, 16 Apr 2026 16:54:23 +0000

If you live inside Claude Code (or any MCP client), the trip from "draft is ready" to "post is live on Dev.to" is friction. You leave the editor, open the Dev.to web app, paste the markdown, fix the canonical URL, set tags, hit publish. That's a workflow you do less often when you're tired.

Here's the same trip without leaving Claude Code.

What you need

A Dev.to API key — generate it in two clicks under "DEV Community API Keys".
The Pipepost MCP server — npm install -g pipepost-mcp.
Claude Code, Cursor, Windsurf, or any MCP client wired to that server.

One-time setup

In your MCP client, add Pipepost as a server. For Claude Code, add this to your mcp.json:

{
  "mcpServers": {
    "pipepost": {
      "command": "npx",
      "args": ["-y", "pipepost-mcp"]
    }
  }
}

Then run setup once to save your Dev.to API key:

setup platform="devto" credentials={api_key: "YOUR_KEY"}

The key gets written to ~/.pipepost/config.json and used for every future call.

Publishing a draft

Open the markdown file you've been writing in Claude Code. Tell the assistant:

Publish this to Dev.to as a draft.

Pipepost reads the file, calls Dev.to's POST /api/articles with published: false, and returns the draft URL. You can review it on Dev.to before flipping the switch.

Publishing live

Same flow, but tell it to publish (or pass published=true). The article goes live immediately and Pipepost returns the canonical URL it landed on.

The detail that matters: canonical URLs

If you're cross-posting (Dev.to + your own blog + Hashnode + Medium), Google needs to know which URL is the source. Dev.to honors a canonical_url field — set it to your own blog post URL and Dev.to will tell search engines "this content lives at the canonical URL, not here."

Pipepost auto-wires this. If you have a blog at pipepost.dev/blog, you can pass canonical_url="https://pipepost.dev/blog/my-slug" and Pipepost forwards it to Dev.to. The result: the Dev.to copy still ranks for branded queries, but doesn't compete with your own blog for the same content.

Tags, cover image, and series

Pipepost passes through everything Dev.to's API supports:

tags — up to 4, no spaces
cover_image — full URL to a hosted image (1000x420 is the recommended ratio)
series — group multi-part posts under one series name
description — overrides the auto-generated meta description

The full schema is in the Pipepost source: src/cms/devto.ts.

What this is good for (and what it isn't)

Good for: developer-blogger workflows where you write in markdown locally, want low-friction publishing, and want canonical URLs handled correctly the first time.

Not for: cases where Dev.to-specific features (like the rich-text editor's image upload) matter to you. The API publishes raw markdown — if you need the WYSIWYG, use the web app.

What about the other platforms?

Pipepost ships clients for Hashnode, Ghost, WordPress, and Medium too. The same MCP call structure works:

hashnode_post body_markdown="..." title="..."
ghost_post html="..." title="..."
wordpress_post content="..." title="..."
medium_post content="..." title="..."

And for promotion: bluesky_post, mastodon_post, linkedin_post, x_post are all in the same server.

The point

Publishing to Dev.to from Claude Code isn't novel — anyone with a curl call and the API docs can do it. The point of an MCP server is removing the steps between "I have a draft" and "it's live": no shell, no API key copy-paste, no checking that you got the canonical URL right, no remembering which tag format Dev.to wants.

If you publish more than once a month, the math works out fast.

Source on GitHub. npm. PRs welcome.

Pipepost v0.8.0: LinkedIn + X posting from any MCP client

PipepostDev — Thu, 16 Apr 2026 16:48:27 +0000

Pipepost is an MCP server that lets your AI assistant publish content end-to-end: SEO scoring, multi-platform publishing, and social broadcast. v0.8.0 adds the two surfaces that were missing — LinkedIn and X — so an MCP client can now reach all the developer-relevant networks without leaving the conversation.

What's in v0.8.0

`linkedin_post`

Posts to LinkedIn via the /v2/ugcPosts endpoint. On first call, Pipepost looks up your person URN from /v2/userinfo and caches it back to your config so subsequent calls skip the round trip. 3000 character limit enforced before the API call so you don't burn quota on a malformed post.

linkedin_post text="Shipping is the only feature that compounds."

`x_post`

Single tweet or reply-chained thread via X v2 /tweets. OAuth 1.0a HMAC-SHA1 signing built in (the X v2 API still requires it for user-context writes). 280 grapheme limit per post — graphemes, not chars, so emoji don't overcount.

x_post text="One. Idea. Per. Tweet."
x_post posts=["thread starts here", "second tweet replies", "third closes"]

The setup friction problem

LinkedIn and X both have OAuth flows that bury you in a forest of scopes, redirect URIs, and token exchanges. v0.8.0 ships scripts/linkedin-auth.mjs to collapse the LinkedIn flow into a single command:

LINKEDIN_CLIENT_ID=xxx LINKEDIN_CLIENT_SECRET=yyy pnpm run linkedin:auth

It spins up a local HTTP server, opens your browser to LinkedIn's consent page, captures the redirect, exchanges the code for an access token, fetches your person URN, and prints a ready-to-paste setup command for Pipepost. No copy-pasting tokens between tabs.

Why a thread chainer

X's API doesn't have a "post a thread" endpoint — you post each tweet individually with reply.in_reply_to_tweet_id pointing at the previous one. x_post accepts a posts array and chains the replies for you, aborting cleanly if any post fails (so you don't end up with a half-published thread).

What I learned about both APIs while building this

LinkedIn: the modern way to identify yourself is OpenID Connect (openid profile scopes, /v2/userinfo returns the sub field, your URN is urn:li:person:<sub>). The old /v2/me endpoint requires the deprecated r_liteprofile scope. Use the new path.

LinkedIn (cont): posting from a company page requires w_organization_social instead of w_member_social, which gates behind LinkedIn Marketing Developer Platform approval (usually 1–4 weeks). v0.8.0 supports personal posting today; company posting will land when MDP approval comes through.

X: the v2 /tweets endpoint accepts JSON bodies but you sign the URL parameters (none, in this case) — the JSON body itself is NOT part of the signature base string. This trips up everyone implementing OAuth 1.0a for v2. The x.ts module in this repo handles it.

X (cont): encodeURIComponent does not percent-encode !, *, ', (, ) — but RFC 3986 (and OAuth 1.0a) requires them encoded. The signature will be wrong if you skip this. There's a one-line rfc3986() helper in the source.

Get it

npm install -g pipepost-mcp@0.8.0

Or via the MCP Registry. Source on GitHub.

Pipepost is built in the open. If you ship MCP servers and want to compare notes on these patterns, the issues tracker on GitHub is open.