MCP Registry Indexer + Capability Matcher
Every AI-agent builder eventually asks the same question: "which MCP server do I need for this task?" There are plenty of Apify actors that wrap Smithery, mcp.so, or Glama. None of them read the canonical, protocol-maintained MCP registry — registry.modelcontextprotocol.io — the source of truth the protocol authors run and the one downstream directories ingest. This actor goes straight to it, and adds the layer nobody else does: an agentic matcher that takes a plain-English task and returns the exact servers that satisfy it.
The MCP ecosystem crossed 19,000 community servers in 2026 and fragmented across vendor directories. The official registry consolidates discovery behind one schema. Building on it means no vendor lock-in, no scraping fragile vendor pages, and no auth. The source is public, keyless JSON.
What it does
- Indexes the full registry into normalized records: server name, title, description, transport (
streamable-http/stdio/sse), remote URL, protocol version, derived capability tags. - Matches a free-text task (
taskQuery) using intent-aware synonym expansion — "search the web and write to a Google Sheet" expands to web/search/google/sheet tokens — and per-field scoring so the strongest title/tag hits rank first. - Monitors freshness (optional) — stores a snapshot in the actor KV store and flags servers added or removed since the previous run, so you catch registry drift or deprecated servers.
Input
{
"taskQuery": "search the web and write the result into a Google Sheet",
"minMatchScore": 20,
"includeCapabilities": true,
"freshnessMonitor": true,
"maxServers": 0
}Output (a match record)
{
"kind": "match",
"server_name": "ai.exa/exa",
"server_title": "Exa",
"description": "Search the web with embeddings...",
"transport": "streamable-http",
"remote_url": "https://mcp.exa.ai/mcp",
"tags": ["web", "search", "api"],
"match_score": 60,
"matched_on": ["search", "web"],
"registry_url": "https://registry.modelcontextprotocol.io/ai.exa/exa"
}A real run against the live registry (capped at 300 servers) returned 282 unique servers and 20 task matches. Top hits for the query above: Google Search Console (60), Exa web search (60), Google News (40), Web Analytics (30). The matcher surfaces multi-intent servers without you reading 19,000 descriptions.
Source quirks we hit
The registry shape is not what third-party scrapers assume. Each response entry wraps { server, _meta }, and the registry returns one entry per version — a single page of 100 entries held only 68 unique servers. Pagination is cursor-based via metadata.nextCursor passed as ?cursor=; ?offset= is ignored (every page returns the same 100). Servers declare capabilities through remotes[] (type + url), not a tools array — so tags are derived from the description, and auth is reported as unspecified (the registry does not expose per-server auth requirements). We dedupe by server.name, keeping the entry flagged isLatest.
Why publishable, why first-mover
Reads only publicly published registry metadata — no personal data, no login, no platform ToS conflict. The agentic task→server matching on the canonical registry is, as far as we can tell, genuinely unbuilt on Apify. The MCP wave is not slowing down; an indexer that answers "what can my agent call right now" sits on the discovery layer everyone else is ignoring.
MCP Registry Indexer + Capability Matcher on Apify. Pay-per-event: a small per-run start fee plus a per-record item fee. Keyless source, so no proxy or per-call API cost.