The problem isn’t quality. Most OSS tools die because the author posted once, got silence, and never had time to keep showing up. Distribution is a recurring job — directory submissions, social posts, content rotation across channels — and for most indie builders it’s either skip it or do it manually every week forever.
I built marketing-pipeline to handle the recurring part.
Onboarding a project takes one command:
marketing onboard --name my-tool --repo owner/repo --kind mcp-server
Enter fullscreen mode Exit fullscreen mode
It fetches the README, sends it to Claude, and writes the problem statement, facts, and content angles to projects.yml. From there, a daily GitHub Actions cron (marketing cycle, 14:00 UTC weekdays) rotates through projects × angles × channels, picks the least-recently-used angle, drafts a post, and publishes it.
For MCP servers specifically, the kind field routes directory submissions to MCP Registry, Smithery, Glama, and PulseMCP automatically. Claude Code skills go to awesome-claude-code (the pipeline generates the payload; their rules require a human to submit via their GitHub issue form once per project — that one step can’t be automated). Browser extensions route to Chrome Web Store, Firefox AMO, and Edge Add-ons.
Social posting covers Bluesky (≤300 chars), X (≤280), Mastodon (≤500), Dev.to, and Hashnode. Per-channel length limits are enforced in code.
The part I spent the most time on: an antislop gate in pipeline/antislop.py that hard-rejects posts before they publish. Banned tokens include ‘excited’, ‘game-changer’, ‘unlock’, ’empower’, ‘AI-powered’, emoji, hashtags, exclamation points, and rhetorical questions. Anything that reads like vendor copy gets killed before it touches an API.
The MCP/agent ecosystem moves fast. Most indie builders in it don’t have distribution infrastructure — they have a README and a prayer. This is the infrastructure layer I wanted to exist.
답글 남기기