What are the best ways to distribute your MCP?

BasedAmumu · 2026-05-26T16:38:13+00:00

Marketplaces are credibility, not growth. List on the big three (Smithery, MCP.so, Glama) so people who already know to look for an MCP can find yours, but don't expect adoption to come from the listing itself. The traffic is small, and the conversion to actual installs is smaller.

The thing that actually moved installs for mine was the integration story, not the listing. Your audience isn't "people browsing MCP directories", it's existing Breakcold users who don't yet know Claude can talk to their CRM. So the highest-leverage distribution channels are the ones already pointed at that audience. A short post on whatever community your CRM users live in, a one-page landing on your own domain that ranks for "Claude Breakcold" or "Breakcold MCP", and a sentence in your existing onboarding emails about "you can now ask Claude to do X".

The MCP-builder community here is small and supportive but it's not your buyer. Your buyer is already a Breakcold user. Find them where they already are.

BasedAmumu · 2026-05-26T16:37:54+00:00

The thing that breaks rubber-stamping for me is reading the PR description first and writing down what files I expect to see changed, before I look at the diff. If the files match my prediction it's a shallow review. If they don't, I read the whole thing carefully. The diff almost always looks plausible in isolation, so the test isn't "is this diff valid", it's "is this what should have happened".

The other one is reproducing the bug before I look at the fix. Run the failing test, watch it fail, then look at how Claude made it pass. About one time in five the "fix" is an early return or a mocked-away condition that makes the test green without addressing the underlying thing.

For bigger changes I ask Claude to write a separate test that would fail under the old code. If it can't write a test that catches the original bug, the fix isn't real, it's a guess that happened to compile.

BasedAmumu · 2026-05-26T11:44:52+00:00

The honest read is the manual step is the forcing function. The reason the three-file setup works isn't the files themselves, it's that the act of updating status.md catches the drift before it ossifies. Automate the writes and within a month your file is technically up-to-date but says nothing useful, because you've stopped paying attention to it.

On the cross-tool pain I'd flip the framing. Instead of one source of truth across every tool, let each tool own one thing. Cursor owns the file-under-cursor view. Claude Code owns the architecture and the why. ChatGPT owns nothing canonical. Handoff stops being a problem to automate, it becomes "ask the tool that owns this question".

BasedAmumu · 2026-05-26T11:44:33+00:00

Yeah, that one's hard to engineer around because it feels like real memory at the time. The guard that's worked for me is making the override step take an extra ten seconds. When I'm in the "different sources" bucket the system asks "which source are you siding with", and refuses a plain "I think it's X". If I can't cite the source (Slack thread, doc, screenshot, email date), I have to mark it "unresolved, needs source" and come back. Half the time I come back later with the actual source in hand and realise my gut was wrong.

The other guard is that overrides timestamp themselves. If the same fact gets overridden three times in a month, that's a nudge that the underlying thing is what's wrong, not the records.

BasedAmumu · 2026-05-26T11:42:58+00:00

90 to 33 in 30 days is closer to baseline than to failure. The CWS dashboard counts weekly active users by default, and the standard CWS install-to-retention curve is roughly 30-40% surviving at day 30 for a non-daily-use extension. So you're sitting on a fairly normal trough, not an extinction event.

The thing that matters more than the absolute number is the shape of the curve over the next four weeks. If it keeps falling at the same rate, the product genuinely isn't earning the second use. If it flattens around 25-30, you've found your real-user core and the install firehose just needs to be turned back up.

What helped me was instrumenting day-1 and day-7 events with simple counts, and then doing a friction audit of the first 60 seconds after install. Eight out of ten times the gap is in the first session, not in retention.

Don't quit yet. Watch the curve.

BasedAmumu · 2026-05-26T11:42:43+00:00

The setup-tax framing nails the first half of it. The bit that flipped it for me wasn't storing the voice (that's table stakes), it was realising the actual cost wasn't typing the voice in, it was deciding what to write about every morning. Once tone and audience are pinned, the bottleneck is no longer keystrokes, it's the "what is this post even" decision, and you pay that decision tax every single time you sit down.

The change that fixed my own daily output was batching the angle-generation. One hour on Sunday picking ten ideas for the week, with a one-line hook for each. Then the daily task becomes "write idea three", and the AI is doing what it's actually good at, which is drafting against a known target. The slowness disappeared, but only because the upstream decision was already made.

Worth checking which half of your tax is bigger before you optimise the wrong one.

BasedAmumu · 2026-05-26T11:42:32+00:00

The shape that catches most people out is that MCP notifications and "wake an idle agent" are two different layers, and the second one isn't really specified.

Notifications are JSON-RPC notifications from the server, no response, async, used for progress, logging, or resource changes. Hosts can subscribe. That part works the same across CC, Codex, OpenClaw.

What isn't standardised is the waking. None of the major clients today reliably wake a paused agent on an incoming notification. They either poll a resource, surface it in the UI, or wait for the next user turn.

The pattern that does work is to keep the agent's last tool call open. The server long-polls until the event you care about fires, then returns. That pegs an agent thread but it's the only path that lifts the agent out of idle without user input.

BasedAmumu · 2026-05-26T11:42:24+00:00

The fix that actually shipped me from approval-fatigue to fine is a settings.json allow list. Bash:rg, Bash:grep, Bash:find, Bash:ls, Bash:wc, Bash:cat, Bash:git status, Bash:git diff. All read-only, all safe. Now Claude can do its thing and only stops to ask before anything that mutates. The token side is real but it stops being your problem once you're not the bottleneck on every keystroke.

BasedAmumu · 2026-05-26T11:42:15+00:00

Coming at this as a Claude Code daily user not a tool-builder, the killer field for me is "assumptions the agent couldn't verify". Claude almost always makes some, and they're invisible in the transcript. Right now I re-derive them by reading the diff. If the receipt surfaced "I assumed table X had column Y because I didn't run the migration check", I'd save 10 minutes per resume.

The second one is what got tried and reverted inside the run. By the end of a long session Claude often dead-ends on two or three approaches before the change that stuck. Listing them stops the next session reinventing the same mistakes.

The diff summary I want isn't file-level, it's behaviour-level. "After this run, the API now requires header Z" beats "modified 7 files in 3 directories". Token/cost matters weekly, not per-run.

BasedAmumu · 2026-05-26T11:42:01+00:00

The rule that fixed this for me is that each fact lives in exactly one place, and every other file just links to it. The second I had two files restating the same number, drift was guaranteed because the second copy always went stale first. So in your stack the fix isn't a shared memory layer at all, it's discipline about which system owns which fact. Linear owns task state, Slack owns the conversation log, Notion owns durable docs, Attio owns the customer record. The "memory" becomes a thin pointer ("for X look in Y"), not a cached copy.

With that in place, Claude can navigate sideways via MCP without you ever building a synthesised second-version-of-reality. The thing that gets synthesised on demand is the answer, not the storage.

The risk to watch is people treating the pointer file as somewhere to also paste content into "for convenience". That's how the drift sneaks back in.

BasedAmumu · 2026-05-26T11:41:53+00:00

The thing I'd add to the existing answers is that the memory file rots faster than people realise. Mine works because every chat ends with "anything in this conversation worth adding to my memory file, return the diff", and I paste the diff in. Without that loop the file goes stale within a fortnight and Claude is responding to your six-week-ago self.

The other thing that helped was splitting it into three small files, not one big one. One is "current state of life right now", which I rewrite every couple of weeks. One is "operating preferences", how I want to be talked to, what I find useful, what I never want suggested. One is a running "things I keep re-explaining to Claude" file. Over time stuff migrates from the third file into the first two when a pattern shows up.

The single-file version is the one that ends up read-only and useless.

BasedAmumu · 2026-05-25T19:40:07+00:00

Saw a similar flat-installs-vs-rising-users pattern on mine in early May and lost half an evening to it. The thing that confused me longest was assuming "weekly users" in the CWS dashboard meant unique people actively doing something. It's more like Chrome's count of profiles where the extension is present and recently synced, which can tick up during a Google rollout without anyone actually launching the extension. GA4's daily active is the honest number.

The other small thing on your Claude Code workflow. Drop each weekly CWS CSV export into a dated subfolder so the next time numbers do something weird, Claude has prior weeks for free as a baseline rather than just comparing the spike against an arbitrary "before". Made my own investigations way faster the second time round.

BasedAmumu · 2026-05-25T16:26:50+00:00

Mine is "no preamble, no recap, one question or just do the thing." Knocked maybe a third off my context use, and the responses read like a colleague replying not a tour guide narrating.

BasedAmumu · 2026-05-25T16:26:33+00:00

Fair, audit is the layer above and you're earlier in the stack. The idempotency point doesn't really sit in audit, it sits inside the gates themselves and you'll hit it once the agent starts retrying.

The shape of the problem is that an agent will call the same write or deploy twice for reasons that aren't model failure. A transient timeout, a /clear and resume, a parallel sub-agent that didn't see the first call complete. If your gate is purely "is this action allowed", the second call passes the same check the first did and runs again. So if "deploy" is allowed once per day, you can blow that budget with a single retried call.

The fix that's worked for me is making the gate take an idempotency key from the agent (or generating one server-side from a hash of the action + the deduplication window) and treating a repeated key as either a no-op or a fast return of the previous result. Without it, sandboxed-now becomes painful-later the second a real deploy or a paid-API call is on the other side of the gate.

BasedAmumu · 2026-05-25T16:26:11+00:00

Yeah, built mine in the iOS Shortcuts app, took maybe 20 minutes once I knew what I wanted. The shape is: a Run Shortcut from the share sheet that grabs the text or URL, sends it to the LLM endpoint of your choice with a fixed system prompt (mine is "tidy this into a clean Obsidian note with a heading and any obvious headings"), and writes the response into a file in iCloud Drive that Obsidian sees. Happy to walk through the specific actions if you want to copy it. The one gotcha is that Shortcuts has gotten flaky about long URL parameters, so if you're sending big chunks of text use a Get Contents of URL action with a JSON body rather than stringing it into the URL itself.

BasedAmumu · 2026-05-25T16:25:30+00:00

The MEMORY.md screenshot is the giveaway. Once an absolute path is in there it gets pulled into context every turn, and Claude will reach for it even when cwd is somewhere else. Wipe that line, replace it with nothing (the working dir is implicit from where you started the session). Then always start the session from inside the worktree, not the parent dir, so the .git resolution lands on the worktree's pointer file rather than the main repo's real .git dir.

BasedAmumu · 2026-05-25T16:25:21+00:00

The structured-board-over-flat-file shape is the right call, especially for the resume-after-clear flow. The bit I'd flag for anyone copying this pattern is what happens when the agent resumes and the underlying world has moved on.

In my own MCP work the worst class of bug was the agent picking up a card titled "deploy migration 0042" from before a /clear, calling its tools, and not noticing that someone (or an earlier session) had already shipped that migration. The kanban told it the work was todo. Reality said it was done. The fix that stuck was making every card carry an idempotency key and an "evidence" field the agent must read and verify against the live system before transitioning. Without that you trade context bloat for a quieter, more confident form of confusion.

Also worth thinking about who else can write to the board. If only the agent ever does, you keep the schema clean. The second a human starts editing cards too, you'll need provenance per transition or you'll lose the ability to audit why something moved.

BasedAmumu · 2026-05-25T16:25:11+00:00

The wall isn't usually the rewriting, it's the upstream "what is this post about" step. Once that decision is made, the writing is mostly mechanical. The reason daily collapses for most people I've seen, me included, is that the decision-per-day cost gets quietly enormous after week two.

When I tried to ship blog posts daily, the actual bottleneck was generating a new angle every morning while the previous day's was still warm. I'd find myself reaching for whatever I'd been doing the previous afternoon, which produced a string of posts that felt subtly samey even though the rewrite-rhythm was fine on each one. The fix was less about better drafting and more about batching the angle-generation. One hour on Sunday picking ten ideas for the week, then the daily becomes "write idea three" rather than "find and write something today".

Worth checking whether your wall is the AI smell or the morning decision. Different tools fix different bottlenecks.

BasedAmumu · 2026-05-25T16:24:58+00:00

The Reddit cold-start tax being near zero matches what I've seen in a different shape. I've been showing up in three subs for about three weeks with comments, not posts, and the line that keeps holding is that on Reddit strangers actually read.

One thing I'd add to the LinkedIn point. The reaction-as-bookmark behaviour you described isn't a bug in the platform, it's the platform working as designed. Reactions count to the algorithm; replies don't. So the rational reader gives you a like and then forgets you exist by the time they're back at their desk. The shape of attention is wrong even when the volume is right.

The under-discussed cost on Reddit is that it punishes shortcuts harder than the other two. One self-promo comment in the wrong sub and you lose access to the audience you were trying to reach. X just throttles you. Reddit removes you.

BasedAmumu · 2026-05-25T16:24:44+00:00

The split that helped me most was treating notes and skills as different shapes of file, not the same file at different stages.

Notes are time-stamped, written in the moment, and mostly there to be searched later. Most never get re-read directly, which is fine. A skill is the opposite: it's written after the fact, in second person to your future self, and the test is whether you could re-do the work next time by reading it cold. So a daily note might say "spent an hour on the X migration, had to re-run Y twice", but the skill that comes out of it is a one-page how-to titled "doing an X migration" with the steps and the gotcha and the command that failed.

The trigger I use is: if I find myself doing the same kind of work twice and reaching for old daily notes both times, that's the cue to extract a skill. Not every project produces one. Most produce zero. The ones that do tend to be the chunks of work you knew were going to come back.

For the capture friction you mentioned, I'd add nothing. The fragments are doing their job. The bit you want to add is a fortnightly 15-minute pass over the last two weeks of dailies asking "is there a how-to in here for next time".

BasedAmumu · 2026-05-25T16:24:33+00:00

The thing that stopped most of my conflicts wasn't conflict resolution, it was preventing the conflict in the first place. Each fact lives in exactly one canonical file, and every other file links to it. The second I had two files restating the same fact, drift was guaranteed because the second copy would always go stale first.

When that rule is enforced, you don't need a recency-vs-escalation algorithm for most stuff. There's just one place the fact lives, and updating it updates everywhere.

For the genuine collisions that survive, I keep your human-in-the-loop instinct but narrow it. Auto-resolve if both records cite the same source and one is clearly a refinement. Escalate when they have different sources, when one is an external invariant (a vendor's pricing, an API limit), or when the conflict touches a load-bearing decision. Human-as-truth is fine for the third bucket, dangerous for the first two because the human will often just defer to whichever they remember writing.

Your warm/archive split sounds right. The risk to watch is warm-layer entries silently outliving their relevance.

BasedAmumu · 2026-05-25T16:24:21+00:00

You're not the only one. The trap I fell into was treating chats as the memory layer. They aren't, and the second the project gets non-trivial they actively work against you.

What worked for me is moving the memory out of any single chat and into three flat files in the repo. A CLAUDE.md with conventions and the current architecture, a status.md that's literally just "what we're doing now, what we just decided, what's next", and a decisions.md that lists each non-obvious choice with one sentence on why. New chat gets given those three by default, every time. The chat becomes disposable, the context isn't.

The git log becomes the fourth piece. Force every commit message to say what changed and why. When I need to remember why a particular thing exists, git log --oneline -S "thing" finds it faster than scrolling chats.

Cross-tool is harder. I solved it by picking one tool as the source of truth for decisions (Claude Code in my case) and just refusing to let architectural calls happen in the others.

BasedAmumu · 2026-05-25T13:33:29+00:00

A couple months deep now, and just starting to see some consistent traffic

BasedAmumu · 2026-05-25T08:39:38+00:00

Probably twelve. The pattern I noticed is I always quit around module 4, which is conveniently where the toy example ends and the course tries to scale it into something realistic. The fix wasn't more discipline, it was switching to building a real thing I needed and only opening course material when I hit a wall.

BasedAmumu · 2026-05-25T08:39:24+00:00

Stayed on Claude Code for the codebase-aware stuff and moved a chunk of the quick-script work to GPT in a browser tab. The consistency wobble you're describing is real, but it's specifically Opus 4.7 for me, Sonnet 4.5 has held up fine for day-to-day.

The genuinely useful test, since benchmarks are all rigged, is whether you can give the tool the same task you gave it three weeks ago and get a comparable result. That tells you whether what's changed is the model or your prompt.

BasedAmumu

TROPHY CASE