Where Agents Actually Find MCP Servers in 2026

The registries your users and their agents actually query, the official MCP Registry API you can curl right now, and why a fresh npm release is not enough if the listing behind it is stale.

By MetricBridge · Updated 5 October 2026 · ~8 min read

Quick answer. Agents find MCP servers through a short chain. You publish the binary to npm or PyPI, publish the metadata to the official MCP Registry, and the big directories (Glama, PulseMCP, mcp.so, Smithery and others) index what the registry and the package managers expose. The registry is the source of truth, the directories are cached copies of it, and freshness is what decides whether a client installs the build you shipped last week or the one you shipped in June.

The four places a server can be found

  1. Package registries (npm, PyPI). This is the artifact: the code a client actually runs.
  2. The official MCP Registry (registry.modelcontextprotocol.io). This is the metadata source of truth: name, version, repository, transport.
  3. Directories (Glama, PulseMCP, mcp.so, Smithery, mcpservers.org, MCP.Directory, and the awesome- lists). This is reach, and each one re-scans on its own schedule.
  4. The answer layer (LLMs and coding agents trained on docs, READMEs and directory pages). This is where "which server should I use?" gets answered with no click.

A client like Claude Desktop never browses a registry at runtime. Someone, or an agent acting for them, reads a listing, copies a config, and the client launches your server.mjs. Discovery is a human and an LLM problem, and registries are where both look.

The registry API is public, and you can curl it

The official registry exposes HTTP, not just a web page. Resolve any server to its current version in one call:

curl -sS "https://registry.modelcontextprotocol.io/v0/servers/io.github.PhilipAD%2Fhealth-export-mcp/versions/latest"

Here is the real response, trimmed to the parts that matter (checked 5 October 2026):

{
  "server": {
    "$schema": "https://static.modelcontextprotocol.io/schemas/2025-12-11/server.schema.json",
    "name": "io.github.PhilipAD/health-export-mcp",
    "description": "Query 190 Apple Health metrics from any MCP agent: zero-dependency, read-only, local-first.",
    "repository": { "url": "https://github.com/PhilipAD/health-export-mcp", "source": "github" },
    "version": "1.5.0",
    "packages": [
      {
        "registryType": "npm",
        "identifier": "health-export-mcp",
        "version": "1.5.0",
        "transport": { "type": "stdio" }
      }
    ]
  },
  "_meta": {
    "io.modelcontextprotocol.registry/official": {
      "status": "active",
      "publishedAt": "2026-10-02T01:34:47.844422Z",
      "updatedAt": "2026-10-02T01:34:47.844422Z",
      "isLatest": true
    }
  }
}

Four fields carry the weight: version, the updatedAt timestamp, the isLatest boolean, and status ("active" means the listing is live). Everything else is metadata a client or directory can render, and packages[].version is the pointer to the npm artifact.

You can also list and search. This returns every published version of every matching server, each with its own _meta block, plus a metadata.nextCursor you feed back as cursor= to page:

curl -sS "https://registry.modelcontextprotocol.io/v0/servers?search=health-export-mcp&limit=20"

Two more parameters matter for anything automated. version=latest resolves a server in one call without walking the history, and updated_since=2026-10-01T00:00:00Z returns only servers touched after a timestamp. That last one is how an agent checks, cheaply, whether the thing it depends on has moved.

Freshness is the ranking signal

Directories sort and re-scan by updatedAt. Glama reports 96,262 MCP servers indexed as of 5 October 2026 and describes itself as a superset of the official registry, re-scanned and quality-scored. PulseMCP markets a directory "updated daily". When a directory decides what to re-crawl, or which listing to put in front of a searcher, the thing it trusts is the timestamp your publish wrote. A server whose updatedAt says June is not wrong. It is just invisible next to one that says yesterday.

This is the part people miss: the registry stores metadata, not the binary. Publish 1.5.0 to npm and forget the registry, and the registry keeps serving 1.4.3 with isLatest: true, so version=latest installs the old build. Two systems, two commands, guaranteed drift.

A real freshness gap, with numbers

Take our own server, checked on 5 October 2026. health-export-mcp is on npm at 1.5.0: zero runtime dependencies, a single server.mjs entry point, Node 18 or newer, 295,133 bytes unpacked. The registry holds eight published versions of it, and version=latest resolves to 1.5.0 with updatedAt: 2026-10-02T01:34:47.844422Z. Both were published the same day, so the pair is in sync. When they are not, an agent silently installs the stale build and reports a bug you already fixed.

Directory lag runs longer than registry lag. As of 5 October 2026, Glama's listing for that same server still carries the pre-rename brand in its page title, weeks after the app became MetricBridge. Registries and directories cache what they first scanned. A rename, a new tool, or a new version does not propagate on its own; something has to re-scan it.

Raw totals overstate reality too. Third-party analyses through August 2026 counted 71,000+ servers on Glama and 22,000+ on PulseMCP, with abandoned and duplicate listings inflating every number. A live isLatest flag beats a large number on a homepage.

Audit your own listing in 60 seconds

Four commands tell you whether your server is discoverable and current.

  1. Resolve latest. Run the versions/latest call for your namespace and read version and isLatest.
  2. Compare to the artifact. Run npm view <your-package> version. If the registry version trails npm, republish. Ours read 1.5.0 on both, with 489 downloads for the week of 27 September to 3 October 2026.
  3. Confirm the listing is active. Check that status is active, not deprecated.
  4. List the history. curl -sS "https://registry.modelcontextprotocol.io/v0/servers?search=<your-server>&limit=50". Gaps between updatedAt dates are the weeks the listing went stale.

If you are mid-release, do the registry step in the same session as npm publish. mcp-publisher writes the server.json metadata, and that file is the same shape the registry returns, so a diff between the two shows what you meant to ship against what the ecosystem can see.

The one-line test. Ask an AI engine "how do I connect Apple Health to Claude?" If your server's name, description and install command do not come back, the problem is not your code. It is a stale updatedAt somewhere upstream.

What this means if your server touches health data

Discovery is the first filter a user applies, and for health data the filter is starker than for most categories. A directory that ranks a cloud-hosted connector above a local one is not making a privacy judgement. It is reading timestamps. If your server is local and read-only, say so in the registry description, because that string is what a directory and an LLM both quote. Ours reads "Query 190 Apple Health metrics from any MCP agent: zero-dependency, read-only, local-first", and that single line does more discovery work than any badge.

The honest limit: none of this measures whether an agent installs you. Downloads and registry resolves are proxies. The registry API is the closest thing to a factual answer about what version the ecosystem can see, which makes keeping it fresh the cheapest discovery work available.

FAQ

Where do AI agents actually find MCP servers?

Through package registries (npm, PyPI) for the artifact, the official MCP Registry for metadata, and third-party directories like Glama, PulseMCP, mcp.so and Smithery for reach. MCP clients do not browse at runtime; a human or an agent reads a listing and pastes a config.

What is the official MCP Registry and how do I query it?

It is the vendor-neutral index of MCP server metadata. Its HTTP API is public at registry.modelcontextprotocol.io/v0/servers: use search= to find servers, version=latest to resolve one, and updated_since= to fetch only servers changed after a timestamp.

Why does registry freshness matter if npm already has my latest version?

Because the registry stores metadata that points at a package version, not the package itself. If you bump npm without republishing the registry entry, version=latest keeps returning the older build, and clients install that.

How do I check whether my listing is stale?

Resolve version=latest, compare its version to npm view <package> version, and read the updatedAt and isLatest fields inside the _meta block. A version trailing your package manager, or isLatest: false, is stale.

Do directories like Glama or PulseMCP update automatically?

They re-scan and cache on their own schedule, and they lag behind the source. Glama still showed our server under its pre-rename name weeks after the rename. Treat a directory as a cached copy and the official registry as canonical.

Apple Health, as clean local JSON for your agent

MetricBridge exports 190 Apple Health metrics as read-only local JSON, and health-export-mcp is the zero-dependency MCP server that reads it. One $24.99 one-time purchase, no account, no subscription.

Read the MCP docs Get the app & setup

Related reading

MetricBridge · Apple Health → your AI agent, privately. · Home · Privacy · Terms · Support