We 2.5x'd our MCP server's tool count and nobody could see it — the registry doesn't auto-update
Quick lesson from building Crawlora (a hosted web-scraping API + MCP server for AI agents). We've been shipping new endpoints steadily — went from ~320 tools to ~800 over a couple months. I assumed the public MCP registry listing (the one Claude/Cursor/etc. pull server info from when someone installs you) reflected that automatically.
It didn't. The registry entry is a versioned snapshot — you have to explicitly re-publish it every time your server's manifest changes, or the listing quietly goes stale while your actual server has moved on. We didn't notice for weeks; anyone finding us through the registry during that window was seeing a 6-week-old tool count.
Small thing, but it's the kind of gap that's easy to miss when "ship the feature" gets all the attention and "keep the listing honest" is a separate, unglamorous checklist item. It's part of the release process now, not an afterthought.
Anyone else running an MCP server (or any kind of public catalog/registry listing) hit something like this? Curious how others are handling freshness as their surface area grows.
This is such a common startup problem: building the thing is only half the battle. The other half is making sure people can actually discover and understand what changed.
Adding more tools/features feels like a big milestone internally, but if the outside world can't see that progress, it almost doesn't exist.
I've noticed the same pattern with SaaS landing pages too. Teams keep shipping improvements, but the homepage stays stuck explaining the old version. New capabilities never get a chance to create demand because the message doesn't evolve with the product.
A small communication gap can make a big product update look like no update happened at all.
The registry-is-a-versioned-snapshot lesson is a genuinely useful catch, and "keep the listing honest is a separate unglamorous checklist item" is the kind of thing everyone learns the expensive way. Adding it to the release process is right. But there's a bigger question hiding in your own numbers: you went from 320 to 800 tools, and the fact that "nobody could see it" almost didn't matter is the real signal.
The uncomfortable version: at 800 tools, tool count has probably stopped being a selling point and started being a liability. An AI agent (and the human choosing your server) doesn't want the most tools, it wants to find the right tool fast. Past a threshold, more tools means more surface for the model to get confused, pick wrong, or burn context reading the manifest. So the stale listing under-selling your count may have cost less than you think, because raw count isn't what makes an MCP server good. Discoverability within it is.
Which reframes your freshness question into a sharper one. The staleness is a symptom of a scaling problem you'll hit harder: as surface area grows, the bottleneck isn't keeping the count current, it's helping agents navigate 800 tools without drowning. The teams that win the MCP space won't have the most endpoints, they'll be the ones whose tools are best organized, named, and described so the model picks correctly first try. That's the freshness problem that compounds.
To your literal question: steal from how large API providers handle this, treat the manifest like a product surface, not a changelog. Auto-publish on manifest change (so staleness is impossible by construction, not by discipline), plus grouping/namespacing so 800 tools present as a navigable structure, not a flat wall. The automation kills the checklist problem you described; the structure kills the one coming.
What's your current story for an agent finding the right tool among 800? That's the freshness question that'll matter more than the count next.
The "versioned snapshot, not a live reflection" distinction is the actual bug here, and it's a specific instance of a gap that shows up constantly with any external catalog: the mental model of "I updated my thing, so anywhere it's listed updates too" is almost never true unless someone explicitly built the sync. Sitemaps, app store listings, directory submissions, all the same trap, just with different re-publish mechanics.
Making "keep the listing honest" a checklist item in the release process rather than a one-off fix is the right response, since the root cause wasn't the stale listing itself, it was that freshness had no owner in the workflow at all.