MCPserver.in

Public authority for MCP server discovery

Publication Methodology

MCPserver.in publishes only what can be evidenced. Server eligibility requires a non-placeholder implementation, documented capabilities, identifiable maintainer, and verifiable source provenance. Editorial content requires published status, required sections, and source references. Comparisons are published only when both sides are evidence-backed and meaningful differences exist. Unknown remains unknown — no fabricated ratings, rankings, or certifications.

Key takeaways

  • Server publication: isServerIndexable() = published + evidence + verified + no noindex.
  • Editorial publication: isContentIndexable() = published + no noindex + required content + required evidence.
  • Comparisons require two qualified entities, real decision context, and non-trivial differences.
  • No fake ratings, stars, or compliance claims without authoritative evidence.
  • Stale content is flagged at 90 days; corrections update reviewedAt with a change note.
  • Indexed legacy URLs are evaluated via Milestone 7 canonical-owner analysis before any redirect.

Server eligibility

A server entity becomes a public, indexable page on MCPserver.in only when it satisfies the centralized publication authority isServerIndexable(). This function evaluates four conditions:

  1. Published status — The server entry in the registry has publicationStatus: "published". Draft, unverified, and archived entries are never indexable.
  2. Evidence exists — At least one evidence reference is recorded in the ledger (evidenceRefs.length > 0).
  3. Evidence is verified — At least one evidence reference has status: "verified", meaning the capability was independently confirmed against a primary source.
  4. No noindex flag — The entry does not carry an explicit noindex: true override.

These conditions are necessary and sufficient. Historical Google indexing, popularity, or maintainer reputation do not override the Evidence Ledger rules.

What qualifies as a non-placeholder implementation

  • Source code is publicly accessible (repository URL in ledger).
  • The server implements the MCP initialization handshake and at least one primitive (tools, resources, or prompts).
  • The server exposes at least one tool with a declared input schema.
  • The server is installable/runnable (package, container, or binary with documented launch instructions).

What disqualifies a server

  • Security-holding package names (e.g., npm *-security placeholders).
  • Initial-upload placeholders on PyPI/npm with no implementation.
  • Announcements, RFCs, or design docs without working code.
  • Forks or copies without independent maintenance.

Editorial content eligibility

Editorial pages (Learn, Clients, Build, Guides, Security) use a separate predicate:isContentIndexable(). This predicate never overrides server publication rules. It evaluates:

  • Status = published
  • No noindex flag
  • Required content sections exist (TL;DR, substantive body, evidence/sources)
  • Required evidence/source references exist for factual claims

Draft, review, quarantine, and retired editorial entries are never indexable.

Comparisons and recommendations

MCPserver.in publishes a comparison page only when all of the following are true:

  • Two or more server entities satisfy the server publication authority (both are indexable).
  • A real search intent exists — users face a genuine decision between the options.
  • Meaningful, evidenced differences exist (capabilities, transport, auth, read/write behavior, limitations).

Comparison tables are structured data drawn from the Evidence Ledger. They compare:

  • Capabilities exposed (tools, resources, prompts)
  • Transport (stdio, Streamable HTTP, SSE)
  • Authentication (none, bearer, OAuth, API key)
  • Read/write behavior (read-only, mutating, mixed)
  • Known limitations (from ledger findings)
  • Use-case fit

We never use: numeric scores, star ratings, "#1" claims, "fastest", "most popular", "best" without qualification. Recommendations are framed as "qualified for [use case] because [evidenced reason]".

Freshness and review cadence

Every indexable entity has a reviewedAttimestamp sourced from the Evidence Ledger. The review cadence:

  • Server entities — Reviewed when a new version is released, when the repository has significant commits, or at least every 90 days.
  • Editorial pages — Reviewed when the underlying protocol, client, or ecosystem changes materially, or at least every 180 days.
  • Trust routes (/evidence, /methodology, /editorial-policy, /about) — Reviewed on process changes or quarterly.

The reviewedAt date on each page is the ledger's most recent review date. It is not a "last modified" timestamp for typographical edits.

Unknown-data handling

The core truth rule: Unknown remains unknown. We never fabricate:

  • Ratings, reviews, or scores
  • Pricing, downloads, or usage statistics
  • Popularity rankings
  • Security or compliance certifications
  • Uptime, latency, or region claims
  • Maintainer status (active/inactive/abandoned)
  • Compatibility matrices without evidence
  • Transport or authentication support without verification
  • Official status or endorsement

When evidence is absent, the page states "Unknown" or "Not verified" explicitly. Absence of evidence is not evidence of absence — it is simply unknown.

Corrections process

When an error is identified in the Evidence Ledger or on a public page:

  1. The ledger entry is updated with the corrected finding.
  2. The reviewedAt timestamp is updated to the correction date.
  3. A correction note is added to the ledger entry describing what changed and why.
  4. The affected public page(s) are regenerated on the next build.
  5. If the correction changes publication eligibility (indexable → non-indexable or vice versa), the sitemap and llms.txt are regenerated accordingly.

Corrections are not hidden. The ledger is the source of truth; public pages are a projection of it.