MCPera · Docs Business & Feasibility Plan
Chapter 04 · Updated 2026-10-13

Product, Programmatic SEO, Business Model & Risks

Continue the existing zero-build static site; grow the whole site via "data → template-generated static HTML/JSON". Hosting is zero-cost, performance is good, and it is SEO-friendly; interactions (search/filter) use the front end reading static JSON shards or edge functions.

5.1 Page-type matrix (every page type is driven by real records — no thin doorway pages)

  • Detail page /server/<slug>: name/one-liner/category; availability badge (tested today); transport + copy-ready config snippet; client compatibility table; pricing/auth card (with source + verification date); tool count and examples; activity (GitHub/npm); version and update history; peer comparisons/alternatives; community feedback; a clear "last verified X hours ago / inactive" marker (A-013 staleness flag).
  • Category/scenario pages /<category>/: e.g. /finance/, /search/, /code/, /email/; each includes "how to choose + a ranked verified table + recommended combos" — high-intent long-tail landing pages.
  • Client-compatibility pages /clients/<client>/: "MCPs that work with Cursor" / "MCPs that work with Claude Desktop" — produced directly by the probe matrix; exclusive and high purchase-intent.
  • Compare/alternative pages /vs/<a>-vs-<b>/, /alternatives/<slug>: high-frequency B2B selection queries; structured comparison + pricing/availability differences.
  • Pricing aggregation pages /pricing/, /pricing/free, /pricing/freemium: strong long tail on commercial fields ("best free / cheapest MCP").
  • Ranking /ranking: use a transparent multi-factor score (measured usability, activity, useCount signals, maintenance, community) — no fake ratingCount; the formula is public and appealable to protect neutrality.
  • Editorial / weekly reports: newest / supply-cut / price-drop / fastest-growing lists — time-sensitive content and return visits.

5.2 SEO / GEO engineering (keep and strengthen the existing foundation)

  • The current site already has canonical and WebSite + SoftwareApplication JSON-LD; upgrade to per-page, record-sourced generation: SoftwareApplication (incl. offers/price, operatingSystem, featureList), ItemList (rankings/categories), FAQPage, BreadcrumbList; build a footer SEO/GEO information layer, an internal-link mesh, sitemap, robots (consistent with existing EZCAI best practice).
  • Programmatic sitemap (following PulseMCP's 21,710-entry approach) but emit pages only for records passing a minimum verification threshold, to avoid 20k thin pages being judged spam; dead records become 410/404 or archived rather than force-kept.
  • GEO/AI-answer optimization: each page provides a "machine-readable summary" (standardized JSON + a concise conclusion + tables) so ChatGPT/Perplexity/AI search can cite and link back directly; the data API is itself a distribution surface for Agents.
  • All numbers are real and click-to-source — both the shield against thin-content SEO penalties and a direct fix for "fake statistics (current site's 1,200+/300+/50+)".

6. Moat & monetization

6.1 Moat (why copying the pages won't copy the business)

  1. Verification time series (time dividend): the "usability/compatibility/pricing history" accumulated by continuous probing cannot be reconstructed; the earlier you start, the more valuable it is (A-003 core).
  2. Exclusivity of liveness + compatibility matrix: cross-client, cross-version real results require long-running probe infrastructure and maintenance — a dirty-work barrier.
  3. Data-licensing compliance: self-produced verification data + license-compatible upstream form a legally redistributable clean supply chain; competitors who directly move Data-License-protected data (e.g. Glama's explicit 401) take legal risk.
  4. Neutral brand + appealable rankings: once developers and procurement treat us as "the trusted third party for choosing MCPs", conversion and network effects (vendors proactively claiming/maintaining) self-reinforce.
  5. Dual distribution — programmatic long tail + data API: SEO traffic and machine consumption feed each other data and reinforce the brand.

6.2 Monetization model (B2B-primary, diversified, not ad-dependent)

Revenue line Target Form Start phase
Data API licensing (core profit) enterprises / Agent platforms / OEM versioned read-only API, snapshot export, tiered by volume/seat/SLA; enterprises can run private probes Phase 2+
Premium subscription developer Pro / teams advanced filters, monitoring alerts, comparison-report export, API quota, ad-free end of Phase 1
Vendor growth suite (supply side) MCP vendors/authors page claim, Verified (earned by passing verification, not bought), analytics dashboard, qualified leads, boost/sponsored slot from Phase 1
Affiliate / commission paid MCPs/cloud services referral share on config/signup links from Phase 1 (light)
Private evaluation / white-label / reports large enterprises custom evaluation matrices, white-label directory, quarterly vendor reports Phase 3
Ads — Restrained: relevant sponsorship only; never pollute verification or rankings optional

Pricing principle: basic human-browsed information is free (feeds traffic and SEO); what's paid is continuously updated, integrable, auditable, redistributable data and monitoring — we sell freshness, certainty, and compliance, not a one-time list (anyone can crawl a list).

6.3 Success metrics (North Star and funnel)

  • North Star: weekly count of verified "ready-to-integrate" Servers × times consumed (really-usable supply × actual usage).
  • Funnel: indexed → passes real test → has a detail page → search impressions/clicks → config-copy/outbound conversion → vendor claim → API/subscription payment.
  • Data-quality KPIs (prioritized over traffic): probe coverage, 100% field traceability, median verification freshness, false-positive (marked-alive-but-dead / marked-dead-but-alive) rate, AI-extraction human-rejection rate.

7. Compatibility / migration with the current MCPera site (smooth zero-build evolution)

Current site: index.html + server-details.html + css + js/main.js, fully static, with hard-coded cards and fake numbers. Evolution is not a rewrite:

  1. Keep URLs and brand: keep the domain, nav structure (Explore/Servers/Clients/Ranking/Community), and visual system; evolve server-details.html?id=<slug> into /server/<slug> (301/map old links).
  2. Replace hard-coding with data-driven content: add a data/ directory (the pipeline generates servers.index.json shards + a per-entity <slug>.json); front-end cards render via JS; replace homepage fake stats with a real counter on the same data layer — a single source of truth, so mismatched numbers never recur.
  3. Templatize the detail page: abstract server-details.html into a template; at build time generate a static page + JSON-LD for every entity passing the threshold (aligned with the existing SoftwareApplication structure, fill in real offer prices, and remove the unsupported aggregateRating or replace it with real reviews).
  4. Decouple pipeline from site: ingestion/verification are independent scripts/jobs (Python or Node; Python first) whose only output is writing into data/; the site build only knows the JSON schema, so any upstream change doesn't affect the front-end contract.
  5. Extensibility hooks: reserve category, client, pricing, and i18n fields; a new page type = a new template, without touching the data core; moving later from static generation to "static + edge dynamic search/API" is incremental, not a rewrite.
  6. Boundary with 666/AgentSync: this project is MCPera's own product build; if brought into AgentSync event/CRON orchestration, register it per the existing rotation_registry ownership and delegation rules, without crossing boundaries to modify other families' artifacts.

8. Roadmap (narrow but true, three phases)

Phase 0 (~1–2 weeks) foundation & feasibility closed loop

  • Wire four structured ingestors: official Registry + Smithery + npm + GitHub; land SQLite + raw JSON snapshots; identity resolution v0.
  • Run L0/L1 probes (liveness + initialize handshake) against a batch of high-value remote Servers (100–300 first).
  • Connect the current site to real data/, replace fake numbers, generate the first batch of real detail pages with correct JSON-LD/sitemap.
  • Deliverable: a small-but-true English directory of "tested working today" + a rerunnable pipeline. This phase can already go live to validate traffic.

Phase 1 (~1–2 months) verification layer & SEO scale-up

  • L2 tools/list inventory, AI extraction of pricing/auth (with evidence + confidence), controlled fetch of official/pricing pages; launch category/client/compare/pricing page types.
  • Vendor claims + UGC review; rankings (transparent formula); monitoring-alert prototype; light monetization via premium subscription and affiliate.
  • Scale to thousands of entities, emitting pages only for those above threshold.

Phase 2 (2–4 months) data productization

  • Versioned read-only data API (key/quota/SLA), snapshot export, enterprise monitoring dashboard, supply-cut/redesign webhooks; sell B2B/OEM licenses.
  • L3 client compatibility matrix (multiple client profiles + stdio sandbox install) to establish the exclusive mindshare.

Phase 3 (ongoing): private evaluation/white-label, quarterly vendor reports, multilingual (Chinese), more sources (PyPI/crates/HF/cloud marketplaces), enterprise private-key probes.

Automation discipline (per user preference): low-frequency / long-tail / strong-human-judgment steps (deep reviews of obscure categories, disputed merges, vendor appeals) stay semi-automated + manual — don't over-engineer just to "look fully automatic"; automate only when a real paying or traffic signal appears.

9. Risks & countermeasures

Risk Description Countermeasure
Upstream terms / bans Heavy fetching of sites or APIs may hit ToS/rate limits Rely mainly on official public APIs, rate-limit & cache, respect robots/ToS, take only public data; never scrape-and-redistribute Data-License-protected data (Glama) — self-produce instead
Probe misjudgment Mistaking temporary rate-limiting/geo-block for "down" Failure classification, multi-region/retry, probe self-check (ruler health), mark inactive only after repeated failures, appealable conclusions
AI-extraction hallucination Wrong pricing/auth extraction damages trust Mandatory evidence + confidence, low-confidence not shown, cross-validation with measurements, traceable to source text and time
Wrong entity merge / duplicates Same name across sources causes incorrect merges Conservative resolution + evidence score, suspected dupes not auto-merged; merges are rollback-able (raw is immutable)
Security / malicious packages Installing local stdio packages carries execution risk Container sandbox, network/resource isolation, handshake-only (no business execution), static pre-checks
Thin-content SEO penalty 20k pure-template pages may be judged spam Emit pages only for records that pass verification and are information-dense; archive when dead; give each page exclusive measured data
Official/big-vendor squeeze The official Registry or client platforms build a trust layer The official side has no incentive to do commercial verification or cross-client neutrality; anchor on "neutral third party + cross-client + history + licensable" and we can become their data partner rather than pure rival
Monetization vs neutrality conflict Vendor payment influences rankings Payment ≠ changed verification; badge/ranking rules public and appealable; editorial/commercial separation
Data freshness cost Compute/maintenance for continuously probing tens of thousands Tiered scheduling (high-value high-freq, long-tail low-freq), incremental, caching, budget caps; accept and explicitly label a small amount of stale long-tail data

Overall feasibility verdict: feasible, and Phase 0 is recommended immediately. There is no hard technical blocker (public data sources, handshakable protocol, SQLite + static generation is enough to start); the main investment is continuous-verification engineering and data compliance — precisely the moat. Low investment: it can go live on real data within one to two weeks for validation, so downside is limited; if verified data is procured by enterprises/OEMs, upside is significant.

Appendix A: measured evidence and counting rules (2026-10-13, rerunnable)

  • Official Registry: GET https://registry.modelcontextprotocol.io/v0/servers?limit=100&cursor=…, limit cap 100 (>100 returns 422), cursor in metadata.nextCursor; 50 pages = 5,200 version records, dedup to 1,673 server names (stopped at the ai.starreel prefix due to time — not a full crawl, hence stated as 1,600+); sample had 4,228 with remotes, 2,109 with packages, 67 status=deprecated. Schema: https://static.modelcontextprotocol.io/schemas/2025-12-11/server.schema.json.
  • Smithery: GET https://registry.smithery.ai/servers (default 10/page), pagination.totalCount = 19,932; a record includes useCount/verified/remote/isDeployed/createdAt/homepage/owner/score (score mostly null in practice).
  • PulseMCP: https://www.pulsemcp.com/sitemap.xml (2.67MB), 23,576 total <loc>, of which 21,710 detail URLs matching /servers/.
  • npm: https://registry.npmjs.org/-/v1/search?text=keywords:mcp-server&size=0 → total = 9,775; text=@modelcontextprotocol → 4,187.
  • Docker Hub: https://hub.docker.com/v2/search/repositories/?query=mcp%20server&page_size=1 → count = 408,334 (heavy noise; order-of-magnitude only, not part of the base).
  • Glama: https://glama.ai/api/mcp/v1/servers → HTTP 401, stating an API key is required and data is under an API Data License forbidding unauthorized redistribution (commercialization signal + compliance red line).
  • GitHub: modelcontextprotocol/servers 91,206 stars, not archived, pushed to that day; modelcontextprotocol/registry 7,347 stars.
  • Current site: mcpera.com/index.html is static hard-coded (stats 1,200+/300+/50+ are placeholders), placeholder search; server-details.html JSON-LD contains an unsupported aggregateRating (4.8/248) to be fixed during data-ization.
  • Rerun notes: direct Python-to-registry occasionally hit SSL EOF on this machine; curl was stable; the pagination script can just use curl + cursor.
  • Any precise figure not listed in this appendix (Glama/mcp.so exact coverage, each client's built-in marketplace size) is unverified; measure it at formal kickoff and never use it on external pages.

Appendix B: normalized schema sketch (field level, for Phase 0 table creation)

servers(id PK, slug UNIQUE, display_name, description, canonical_homepage,
        taxonomy_tags JSON, official_status, first_seen_at, last_verified_at,
        trust_score, alias_of NULL, created_at, updated_at)
server_versions(id, server_id FK, version, is_latest, status, published_at,
                source, source_url, fetched_at)
endpoints(id, server_version_id FK, transport ENUM(stdio,streamable-http,sse),
          url NULL, pkg_ecosystem NULL(npm|pypi|docker), pkg_coordinate NULL,
          is_remote BOOL)
vendors(id, name, homepage, verified_bool, claimed_by NULL)
pricing(id, server_id FK, model ENUM(free,freemium,subscription,pay_per_call,contact,one_time),
        currency, amount, unit, free_trial, evidence_quote, source_url,
        fetched_at, confidence ENUM(high,medium,low))
auth(id, server_id FK, type ENUM(none,api_key,oauth,oauth_pat,other),
     doc_url, evidence_quote, confidence, fetched_at)
probe_results(id, server_version_id FK, level 0..3, client_profile, ok BOOL,
              protocol_version, auth_required, auth_method, latency_ms,
              tool_count, capabilities JSON, errors JSON, evidence JSON,
              started_at)            -- immutable, append-only
compatibility(server_version_id, client_profile, status, checked_at, detail)
source_records(id, source, source_url, fetched_at, content_hash, payload_path) -- immutable raw layer
reviews(id, server_id FK, author_kind(user|vendor), body, stars NULL,
        client_profile, created_at, moderated_bool, confidence)
vendor_claims(id, vendor_id FK, server_id FK, status, evidence, reviewed_at)

Data API contract: version prefix /v1/, only add fields (never change/remove old ones); cursor pagination; every response carries generated_at and each record carries last_verified_at / sources[], so consumers can judge freshness and provenance.