2.1 Competitive landscape by tier
| Player | Nature | Measured scale | Notable data dimensions | Monetization | Observable weakness |
|---|---|---|---|---|---|
| Official MCP Registry (modelcontextprotocol/registry, 7,347★; API: registry.modelcontextprotocol.io) | Official authoritative metadata | 1,673+ unique Servers after dedup (sample, not full) | name/version/remotes(transport+url)/packages/status(active/deprecated)/publishedAt/isLatest; schema version present (2025-12-11) | None (public-good infrastructure) | Registers only claims; does not verify usability, mark price, cover client compatibility, or rate; a pure technical registry |
| Smithery (registry.smithery.ai public API) | Commercial Registry + hosted deployment | totalCount 19,932 | useCount, verified, remote, isDeployed, createdAt, homepage, owner, score (score mostly null in practice) | Hosted deployment/distribution, CLI ecosystem (smithery-cli 840★) | Many fields but sparse quality (score empty); centered on its own deploy ecosystem, not a neutral procurement view; no historical timeline |
| PulseMCP | SEO-style directory/community | sitemap 21,710 server pages | Very broad coverage, many long-tail pages, categories/tags | Ads/sponsorship/referral | Mostly aggregation/listing, high thin-content risk, lacks deep verification and B2B data licensing |
| Glama (glama.ai/mcp) | Data-company-style directory | Page 200 (SPA; exact count unverified) | Fine-grained categories, has an API | API Data License, mandatory key, unauthorized redistribution forbidden (explicit in the measured 401) | Data is locked; funnels mainly to its own NLP platform; its licensing model both validates the paid market and leaves an "open & traceable" differentiation gap |
| mcp.so / other SEO directories | Traffic-style directory | Main sitemap only 28 entries (measured 2026-10; likely moved to sub-index or SPA) | Trending lists, Chinese/English SEO | Ads, sponsored slots | Shallow content, noisy, weak monetization, low authority |
GitHub modelcontextprotocol/servers (91,206★) |
Official reference-implementation collection | Single repo | Trusted code samples | None | Just a list of code repositories; no operations/pricing/availability info |
| Client built-in marketplaces (Cursor / Claude etc.) | Channel owner | Unverified | Tightly bound to the vendor's own client | In-platform closed loop | Closed, not cross-client, not neutral; enterprises can't do horizontal procurement from them |
2.2 Key judgment: three layers of competition and MCPera's wedge
Split the market into three layers; the conclusion is "can't win the bottom layer, there's a crack in the middle, and nobody occupies the top layer":
- Registry of Record layer — locked by the official Registry + Smithery; competing on count is a guaranteed loss. MCPera does not rebuild a registry; it consumes the official Registry/Smithery as free upstream (respecting their terms).
- Directory / SEO layer (Discoverability) — PulseMCP/mcp.so have proven long-tail traffic works, but content is shallow and commoditized. MCPera does the same programmatic SEO with verified structured data, giving each page higher information density and credibility — enough to win later on the long tail.
- Trust / procurement layer (Verification & Procurement) — this is a true vacuum. Nobody systematically answers: is it alive now, which clients/versions run it, does it cost money and how is it billed, how is auth configured, how long since an update, what's the availability history, how to choose among peers. MCPera takes this layer and sells it simultaneously as (a) a selection site for humans and (b) a licensed data API for machines.
Essence of the moat (A-003/A-013/A-015 consensus): verification results + historical time series + traceable sources are continuously produced dirty work that a one-off crawl cannot copy; the later you arrive, the more valuable the time dividend (accumulated snapshots), which latecomers cannot backfill.
2.3 Differentiation in one line
The official Registry tells you "someone registered it"; Smithery tells you "it can be deployed"; MCPera tells you "it works today, it runs on your client, and it's worth this price" — and all of that is subscribable, licensable, and auditable over time.
3. Target users and needs (who pays)
Rather than an undifferentiated "whole-industry encyclopedia", focus on three primary user types + one supply-side type based on willingness to pay and data usage.
3.1 Primary user A: application / indie developers (traffic base; free + affiliate)
- Scenario: picking an MCP in Claude/Cursor/a self-built Agent that "can send email / query earnings / operate GitHub", afraid of landmines.
- Real need: does it run right now (one-click config snippet), does it need my own API key, free tier, is it still alive recently, what traps have others hit.
- Payment: free to use, contributing traffic and UGC; monetized via referral/affiliate links to paid MCPs; advanced filtering/export can be paid.
- Product: a detail page with "availability badge + client compatibility table + copy-ready config + pricing/auth card + recent run history".
3.2 Primary user B: enterprise engineering / procurement / innovation teams (high ACV; the main data-licensing battlefield)
- Scenario: evaluating a capability (search, financial data, legal, CRM, internal knowledge) for an enterprise Agent, requiring horizontal comparison and compliance review.
- Real need: a comparable matrix (capabilities / pricing model / auth & security / data residency / SLA / availability history / vendor activity / alternatives), exportable evaluation reports, a stable API/Snapshot for internal systems, and vendor-risk & deprecation alerts.
- Payment: team subscriptions, data API licensing (per seat / call volume / enterprise SLA), private evaluations / white-label directory.
- Product: Compare matrix, Vendor Risk dashboard (deprecation/supply-cut/change monitoring),
/pricing/and/alternatives/pages, webhook alerts, licensed API.
3.3 Primary user C: Agent platforms / clients / integrators (OEM / data licensing; most scalable)
- Scenario: embedding a "tool marketplace / recommendations" inside their own Agent product; they need a clean vendor library with legal re-licensing rights, compatibility annotations, and live status.
- Real need: programmatically callable, stable schema, versioned (
@vN), filterable by transport/client/category/region/price, with deprecation flags. - Payment: API license / white-label / revenue share. Note Glama already locks data with a Data License, indicating OEMs will pay for "compliant redistribution"; MCPera's re-licensable data must come from self-produced verification + license-compatible upstream, never by infringing and copying Glama.
3.4 Supply side D: MCP vendors / indie authors (the supply side of monetization)
- Scenario: acquiring customers and building trust among tens of thousands of commoditized Servers.
- Real need: claim their page, a Verified / Pro badge, publish pricing and updates, get high-quality leads, monitor compatibility across clients.
- Payment: vendor subscription (claim + analytics + boost/badge, kept restrained so neutrality isn't polluted), pay-per-qualified-lead, sponsored reports.
- Neutrality red line: payment buys placement/data enhancement/analytics only, never verification results or ranking manipulation; verification status is equal for all and appealable.
3.5 User priority and cold-start focus
- MVP serves only A + D: use free public data + self-checks to stand up the developer selection site, while opening vendor claims.
- Phase 2 moves to B/C: once verification history and coverage form a moat, sell data licensing and enterprise dashboards — the profit center.
- Edge, low-probability needs (A-015/A-007 consensus) are not automated prematurely: e.g. deep evaluation of obscure private protocols stays semi-automated + manual until a paying signal appears.