How MCP Directories Actually Work — and Which One to Install From
Search for an MCP server and you will land on five different sites offering it. Glama has a page. LobeHub has a page. PulseMCP, mcp.so and Smithery each have their own. They look like app stores, they use words like "install," and they present the impression that you are making a choice.
You are mostly not. Most MCP directories are catalogs, not install surfaces. They index servers, render the metadata, and then hand you the same npx command every other site would have handed you. Which one you found the server on changes nothing about what runs on your machine.
That distinction collapses a confusing decision into a simple one, and the small number of cases where it does matter are the cases that will waste your afternoon if you get them wrong. This article uses App Store Operator — an MCP server for App Store competitive research inside Claude — as the worked example throughout, because it is currently listed across most of these surfaces in visibly different states of freshness, which makes the mechanics easy to see.
All version numbers and API responses below were verified live on 2026-07-25.
The Short Answer
- The official MCP Registry is an API, not a website — the upstream metadata source most directories read from.
- Glama, LobeHub, PulseMCP and mcp.so are catalogs. They help you discover a server; the install instruction they give you is the same command the author publishes.
- Smithery ships a CLI, and the Claude Plugin Directory brokers a reviewed
/plugin install. Those two are genuine install surfaces. - A listing can be months out of date without looking broken. Verify against npm or the registry before trusting a version number on a directory page.
Catalogs vs. Install Surfaces
Every MCP directory falls into one of two categories, and nothing on the page tells you which one you are looking at.
A catalog indexes servers and displays their metadata: name, description, tools, license, repository. Its "Install" section is a rendered string — usually the npx line from the server's own package metadata, sometimes a JSON block for your client's config. Copying it from the directory is identical to copying it from the project's README. A catalog is a search engine with a nice card layout.
An install surface actually performs the installation, through a CLI, a client integration, or a handshake that writes to your config for you. Here the directory is part of the mechanism, not just the discovery step.
| Catalog | Install surface | |
|---|---|---|
| What it gives you | A command to copy | A command that runs |
| Where the server comes from | npm / GitHub, directly | npm / GitHub, brokered by the directory |
| What changes if you pick a different one | Nothing | Update path, config location, trust chain |
| Examples | Glama, LobeHub, PulseMCP, mcp.so | Smithery CLI, Claude Plugin Directory |
The practical consequence: for a catalog, the only question worth asking is "is this listing current?" For an install surface, you are also choosing a maintenance path, and that deserves more thought.
The Official MCP Registry Is the Upstream, Not a Directory
The piece most people miss is that the official registry at registry.modelcontextprotocol.io is not competing with Glama or mcp.so. It sits above them. It is an API with no meaningful browse UI: authors publish a server.json to it, and directories pull from it. That makes it the closest thing the ecosystem has to a source of truth, and the fastest way to check a server's current published state:
curl -s "https://registry.modelcontextprotocol.io/v0.1/servers/io.github.meyusufdemirci%2Fapp-store-operator/versions/latest"
The important field in the response is the canonical name — io.github.meyusufdemirci/app-store-operator. That reverse-DNS form is the registry's namespacing scheme: io.github.<owner>/<server> proves the author controls the matching GitHub account. Two servers can both be called "app store operator" on a catalog page; only one can hold that canonical name.
Swap /versions/latest for /versions and you get the full publish history with timestamps, which is a surprisingly good maintenance signal — more on that below.
What registry presence guarantees: the author controls the namespace, the npm package referenced actually exists, and the version marked isLatest: true is what the author last published.
What it does not guarantee: code quality, that the server works, or that anyone reviewed it. It is an identity and freshness mechanism, not a review board. Treat it the way you treat npm itself.
The Catalogs
Glama
Glama indexes tens of thousands of servers and describes itself as a superset of the official registry — it auto-ingests registry metadata, republishes it, and layers its own quality scoring on top. Its search is good and its API is public:
curl -s -A "Mozilla/5.0" "https://glama.ai/api/mcp/v1/servers/meyusufdemirci/app-store-operator"
One trap worth knowing: the list-projection endpoint returns "tools": [] for every server, including servers whose pages clearly display their tools. It is an artifact of that endpoint, not a signal about the listing. The rendered page is the source of truth.
Glama also offers sandboxed execution for some servers, and that is where a real limitation appears for anything needing a browser session. App Store Operator's analytics tools drive a local Chromium window through Playwright so you can sign in to SensorTower once, and a container cannot perform that sign-in. The honest framing for Glama is therefore find it on Glama, then install it locally — never run it on Glama, because research_rivals and get_app_details will not function in a sandbox however the listing is configured.
LobeHub
LobeHub ingests registry metadata and adds auto-translated descriptions across a large number of languages, which genuinely helps non-English discovery. It also has the clearest stale-listing problem of the four, and App Store Operator is a live demonstration of it:
curl -sL -A "Mozilla/5.0" "https://market.lobehub.com/api/v1/plugins/meyusufdemirci-app-store-operator" \
| python3 -c "
import sys,json
d=json.load(sys.stdin)
print('version :', d.get('version'))
print('validated :', d.get('validatedAt'))"
As of 2026-07-25 that returns version 0.2.1, validated 2026-07-23T06:01:04Z. The current version is 0.3.2, published to npm at 2026-07-23T12:54:13Z — four releases ahead. A bump published seven hours after that validation did not trigger a re-check. The page is not broken and does not look wrong; it just shows an old number indefinitely.
PulseMCP
PulseMCP ingests from the official registry daily and processes weekly, so listings appear on a lag. Its editorial layer — use-case write-ups and comparisons — is the most useful thing it adds.
One caveat if you plan to script against it: the public v0beta API is being deliberately sunset, failing a rising percentage of requests on purpose as the deprecation advances, and the replacement v0.1 API requires an X-API-Key header. Any script still calling api.pulsemcp.com/v0beta/servers is out of date. Use the site search instead.
mcp.so
mcp.so is the largest by raw index size and the one exception to the auto-ingest pattern: it does not pull from the official registry. Listings get there by manual submission. That means absence from mcp.so tells you nothing about a server's legitimacy, and presence tells you only that someone filled in a form.
Its sitemap is public, which makes it the one directory you can exhaustively grep:
for p in $(seq 1 19); do
curl -s -A "Mozilla/5.0" "https://mcp.so/sitemap.xml?section=servers&page=$p" \
| grep -o '<loc>[^<]*</loc>'
done | grep -i app-store-operator
Watch the slug convention — collisions get an owner or hash suffix, so match loosely rather than assuming the bare package name.
The Install Surfaces
Smithery is the one directory in this group that is also a real installer. It ships a CLI, and for a local stdio server it registers the server for discovery while the server still runs on your own machine. Its search API is public and needs no key:
curl -s "https://registry.smithery.ai/servers?q=app-store-operator"
If Smithery is already your install path, using it is a legitimate choice with a real mechanism behind it. If it is not, adopting it to install one server adds a dependency for no benefit — the npx command was always available.
The Claude Plugin Directory is the other genuine install surface, and structurally the most interesting one. It is first-party, human-reviewed before listing, and a plugin can bundle more than an MCP server: tools, skills, slash commands and subagents in a single /plugin install. That review requirement is the meaningful difference from every catalog above — someone at Anthropic looked at it.
How to Tell a Current Listing From a Stale One
This is the only directory skill that actually matters, and it takes about fifteen seconds. Work from the ground up: npm is the truth, the registry mirrors it, the directory reports it.
Step 1 — get the real version from npm.
npm view app-store-operator version
Step 2 — confirm the registry agrees.
curl -s "https://registry.modelcontextprotocol.io/v0.1/servers/io.github.meyusufdemirci%2Fapp-store-operator/versions/latest" \
| python3 -c "
import sys,json
d=json.load(sys.stdin); m=d['_meta']['io.modelcontextprotocol.registry/official']
print(d['server']['version'], '| status', m['status'], '| isLatest', m['isLatest'])"
Both should return 0.3.2, with status: active and isLatest: true. When npm and the registry agree, you have ground truth.
Step 3 — compare the directory against it. Anything older is a stale cache on the directory's side, not a signal about the project.
The corollary is worth internalising: a stale directory listing is almost never the author's fault, and almost never worth acting on. The failure mode is boring — an aggregator validated a package during a window when an older version happened to be current, then never re-validated. App Store Operator's own npm history shows exactly how that happens: 0.2.1 at 05:27 UTC, 0.3.0 at 06:16, 0.3.1 at 07:45, 0.3.2 at 12:54, all on 2026-07-23. Every aggregator that crawled that day latched onto a different version, and the ones that cached early are still showing it.
The gap between npm and the official registry is a different story, and it is what the /versions endpoint is good for. For 0.3.2 that gap was six seconds — npm at 12:54:13Z, registry at 12:54:19Z. That is machine timing rather than hand timing, which tells you the publish pipeline is automated instead of remembered. It is one of the few genuine maintenance signals you can read from outside a project.
Why the Install Command Is Identical Everywhere
Once you have seen the metadata flow, this stops being mysterious. A server's server.json declares its transport (stdio) and its package (registryType: npm, identifier: app-store-operator). Every directory that ingests the registry reads those same facts and renders the only command they can produce: fetch that npm package, run it over stdio. No directory-specific build, no hosted endpoint, no per-directory artifact. The package on npm is the product.
So for a local stdio server on npm — most of the ecosystem — the install line is a function of the package, not of where you found it. Directories differ in discovery quality: search, categorisation, editorial context, translations, how current the metadata is. They do not differ in what gets installed. The install surfaces are the exception because they broker the install rather than describing it, which is exactly why they are the two cases where the choice has consequences.
So Which One Should You Install From?
For a local stdio MCP server, in order:
- The project's own README or website. Shortest path to the truth, always current, and where setup caveats are documented.
- The official registry, to verify identity and freshness before installing anything.
- Any catalog, if that is where you found it — but check the version against step 1 or 2 first.
- Smithery or the Claude Plugin Directory, if you already use them as your install path and want the update mechanism they provide.
If this is all new, the plain-English explanation of MCP servers covers what these servers are and why they run locally, which makes the directory landscape much easier to read.
The Worked Example: Installing App Store Operator
Whichever directory you arrived from, this is the command. It is the same one on every listing:
claude mcp add --transport stdio app-store-operator -- npx -y app-store-operator@latest
Claude Desktop takes the equivalent JSON entry, and because this is a standard stdio server it runs in other MCP clients too — OpenAI Codex takes codex mcp add app-store-operator -- npx -y app-store-operator@latest. Both Claude paths, including first-run behaviour and troubleshooting, are covered in the setup guide.
Four tools become available, and their account requirements differ in a way worth knowing before you install:
search_app_store— ranked App Store results for a keyword and country, up to 25. No account of any kind.prepare_iae— generates App Store Connect-ready In-App Event copy with character limits enforced. Pure local computation, no external calls, no account of any kind.research_rivals— downloads, revenue, ratings, publisher and top markets for the top 3 apps on a keyword. Needs a one-time free SensorTower browser sign-in.get_app_details— the same dataset for specific app IDs you already have. Same one-time free sign-in.
Half the toolset works the moment it starts. The other half opens a visible browser window once so you can sign in to a free SensorTower account; the session is saved to a local profile on your machine and reused from then on. No paid plan, no API key.
Frequently Asked Questions
What is the difference between the MCP registry and an MCP directory?
The official MCP Registry is an API that stores authoritative server metadata, published by the authors themselves and namespaced to prove ownership. A directory is a website that reads that metadata (or collects its own) and presents it for browsing. The registry is the upstream source; directories are the consumer-facing layer on top of it.
Does it matter which MCP directory I install from?
For a local stdio server distributed on npm, almost never — every directory hands you the same command, because the install is determined by the npm package rather than the directory. It matters in two cases: Smithery, which ships a CLI that performs the install, and the Claude Plugin Directory, which brokers a reviewed, bundled install with its own update path.
Why does a directory show an older version than npm?
Because the directory cached its metadata at a moment when that version was current and has not re-validated since. Most catalogs validate on ingest rather than continuously, and a later release does not reliably trigger a re-check. Verify with npm view <package> version and treat the npm answer as authoritative.
Is being in the official MCP registry a quality signal?
It is an identity and freshness signal, not a quality one. It proves the author controls the namespace and that the referenced npm package exists at the stated version. Nobody reviewed the code. Of the surfaces in this article, only the Claude Plugin Directory involves human review.
Can I run an MCP server inside a directory's sandbox instead of installing it?
Sometimes, but check what the server actually does first. Anything that needs a local browser session, filesystem access, or your own credentials will not work in a hosted container. App Store Operator is a clear case: search_app_store and prepare_iae are self-contained, but research_rivals and get_app_details drive a real browser for the SensorTower sign-in, which a sandbox cannot do.
Verify, Then Install
The taxonomy is the durable part. Individual directories will rise, stall and get replaced, but the split between a catalog that helps you find a server and an install surface that helps you run one will not change, because it follows from how MCP servers are actually distributed.
Two commands cover the practical version of all of this. Check what is current:
npm view app-store-operator version
Then install what you verified:
claude mcp add --transport stdio app-store-operator -- npx -y app-store-operator@latest
From there, the 60-second competitor research guide covers the query patterns worth learning first, and the keyword research guide covers what to do with the numbers once you have them.
Run your first competitive research in 60 seconds.
App Store Operator connects Claude to App Store and SensorTower data — no browser, no API keys, no manual copy-paste.
View setup guide →