Evidence Ledger

What the Evidence Ledger is

The Evidence Ledger is a structured record that backs every indexable claim on MCPserver.in. It is not a marketing database and it is not a popularity index. It is an audit trail: for each server entity or editorial assertion, the ledger stores the primary sources that were consulted, the verification outcome, and the date of the last review.

The ledger exists because AI-assisted discovery surfaces claims faster than humans can manually verify them. By making provenance explicit and machine-readable, the ledger lets both human readers and AI answer-extractors trace any claim back to its origin.

Source types and provenance

Every ledger entry carries a source type. The classification determines how much weight the evidence carries in the publication decision:

• official — Authoritative project sources (e.g., modelcontextprotocol.io, github.com/modelcontextprotocol).
• registry — Machine-readable registries or package indexes (npm, PyPI, official MCP registry).
• repository — Source code repositories (GitHub, GitLab) where implementation can be inspected.
• documentation — Published docs, README files, API references.
• package-registry — Package metadata from npm, PyPI, crates.io, etc.
• measurement — Independent test runs, benchmark results, or capability probes executed by MCPserver.in.
• editorial — Internal analysis, methodology documents, or synthesis pages produced by MCPserver.in.

Higher-trust sources (official, measurement, repository) carry more weight than lower-trust sources (package-registry, editorial). A claim supported only by editorial synthesis without primary source backing will not satisfy the publication authority for server entities.

Verification states

Each evidence reference has a verification status:

• verified — The claim was independently confirmed against a primary source (source code, live endpoint, official documentation). The finding is reproducible.
• unverified — The claim comes from a maintainer declaration, marketing material, or secondary source without independent confirmation. It is recorded but does not satisfy the publication authority for server entities.

A server entity requires at least one verified evidence reference to passisServerIndexable(). Editorial pages require verified evidence for any factual claim about external systems.

Measured vs declared

This distinction is critical for server capabilities:

• Declared — The maintainer states the server supports a capability (e.g., "supports OAuth"). This is a declaration.
• Measured — MCPserver.in or a trusted third party has tested the capability (e.g., completed an OAuth flow against the server and received a valid token). This is a measurement.

Declarations alone do not flip a server to verified. Measurements are required for indexable status. Where a capability is declared but not measured, the ledger records it as unverified and the server remains non-indexable until measurement is completed.

Review dates and freshness

Every ledger entry has a reviewedAttimestamp. Entries older than 90 days without a new review are flagged as potentially stale. The editorial process reviews flagged entries on a rolling basis.

Stale entries do not automatically become non-indexable, but they are candidates for quarantine if the underlying system has changed (new major version, repository archived, domain expired).

The reviewedAt date on each public page reflects the ledger's most recent review, not the page publish date.

Publication requirements

For a server entity to be indexable (appear in /servers and sitemap):

• Publication status = published
• Evidence count > 0
• At least one evidence reference with status = verified
• No noindex flag

For an editorial page to be indexable:

• Status = published
• No noindex flag
• Required content sections exist
• Required evidence/source references exist

These rules are enforced at build time. The static generation pipeline filters through the appropriate publication authority before emitting any public route.

Limitations and corrections

• The ledger reflects the state of knowledge at the time of review. It is not a real-time monitoring system.
• Source availability varies: some repositories are private, some package registries lack metadata, some servers have no public documentation.
• Measurement capacity is limited. Not every declared capability can be independently tested.
• Corrections are published as ledger updates with a new reviewedAt date and a note describing the change.

If you identify an error in the ledger, use the correction process described in theEditorial Policy.