Built an MCP server, pushed it to GitHub, posted once, got a handful of stars from people who already follow you, and then it quietly stopped accumulating any traction. The problem wasn't the tool — it was that staying visible requires showing up every day across directories, registries, and social channels, which is a part-time job nobody signed up for.
I built marketing-pipeline to handle the recurring work. One command onboards a project:
marketing onboard --name my-tool --repo owner/repo --kind mcp-server
It fetches the README, runs it through Claude to extract problem statement, factual claims, and content angles, and saves everything to projects.yml. That one run is the only time you touch configuration.
The kind: mcp-server flag matters specifically here. On first run, the pipeline submits to the official MCP Registry, Smithery, and GitHub Topics in one step. The MCP Registry is what Glama and PulseMCP both pull from, so one submission propagates to three indexes automatically.
After that, a daily GitHub Actions cron at 14:00 UTC rotates through your projects, picks the least-recently-used content angle, generates channel-appropriate posts (Bluesky at 300 chars, X at 280, Mastodon and Dev.to/Hashnode with their own constraints), and publishes them. It doesn't repeat angles until the full rotation is exhausted.
The part I spent the most time on is the antislop gate in pipeline/antislop.py. Before any post gets published, it hard-rejects a token list: excited, game-changer, unlock, empower, AI-powered, emoji, hashtags, exclamation points, rhetorical questions. Every post that goes out reads like a practitioner wrote it, because those tokens are a hard failure condition, not a style suggestion.
The tradeoff worth naming: awesome-claude-code submission can't be automated because their rules require a human to submit via their GitHub issue form. The pipeline generates the payload, but you have to click submit once.
Top comments (0)