DEV Community

J Now
J Now

Posted on

Why most MCP servers stay invisible after launch

The MCP ecosystem is moving fast. New servers ship every week, but there's no distribution infrastructure built for indie builders — no equivalent of Product Hunt for agents, no curator reliably picking up your tool. You submit to one directory, maybe post once on Bluesky, and then the work of showing up consistently loses to whatever you're actually building.

I wrote marketing-pipeline to handle that recurring work. The angle that mattered to me was MCP servers specifically: one command onboards a project.

marketing onboard --name my-tool --repo owner/repo --kind mcp-server
Enter fullscreen mode Exit fullscreen mode

It fetches your README, extracts the problem, facts, and content angles into projects.yml, and routes the project to the right directories — MCP Registry, Smithery, Glama, PulseMCP — based on the kind field. Claude Code skills route to awesome-claude-code instead; browser extensions go to the Chrome Web Store submission queue.

From there, a GitHub Actions cron runs at 14:00 UTC on weekdays. It rotates through projects × angles × channels, picks the least-recently-used angle, drafts a post, and publishes. Bluesky, Dev.to, Hashnode, Mastodon. Per-channel character limits are enforced in code: 280 for X, 300 for Bluesky, 500 for Mastodon, 150–400 words for Dev.to and Hashnode.

The part I spent the most time on was the anti-slop gate in pipeline/antislop.py. It hard-rejects specific tokens — 'excited', 'game-changer', 'AI-powered', emoji, hashtags, exclamation points — before anything goes out. The posts that survive read like a practitioner wrote them, not a marketing template.

One constraint worth knowing: awesome-claude-code submissions can't be automated. Their rules require a human to file a GitHub issue. The pipeline generates the payload and flags it; you submit once, manually.

github.com/robertnowell/marketing-pipeline

Top comments (0)