MCPserver.in

Public authority for MCP server discovery

Editorial Policy

MCPserver.in is an evidence-backed knowledge resource for the Model Context Protocol ecosystem. We do not fabricate facts, ratings, or rankings. Every public claim traces to a primary source in the Evidence Ledger. Recommendations are qualified by evidenced capability fit, not subjective scores. Commercial relationships do not influence publication decisions. Stale content is flagged and reviewed. Corrections are transparent and update the ledger.

Key takeaways

  • Zero tolerance for fabricated facts: ratings, reviews, pricing, popularity, certifications, uptime, compatibility.
  • Every factual claim about an external system requires a ledger entry with a primary source URL.
  • Recommendations = evidenced capability fit for a use case, never numeric scores or star ratings.
  • No commercial influence on server eligibility, editorial coverage, or comparison outcomes.
  • Stale entries flagged at 90 days (servers) / 180 days (editorial); quarantine if underlying system changed.
  • Corrections update the ledger, bump reviewedAt, add a change note, and regenerate affected pages.

No fabricated facts

The following categories of information are never fabricated on MCPserver.in. If authoritative evidence does not exist, the value is stated as "Unknown" or "Not verified":

  • Ratings, review scores, or star ratings
  • Pricing, licensing costs, or commercial terms
  • Download counts, usage statistics, or popularity metrics
  • Security certifications (SOC 2, ISO 27001, FedRAMP, etc.)
  • Compliance certifications (GDPR, HIPAA, PCI-DSS, etc.)
  • Uptime guarantees, SLA commitments, or latency benchmarks
  • Regional availability or data residency claims
  • Maintainer status (active, inactive, abandoned, deprecated)
  • Compatibility matrices (client × server, transport × server)
  • Transport support (stdio, HTTP, SSE, WebSocket) without verification
  • Authentication support (OAuth, API key, mTLS, etc.) without verification
  • Official status, endorsement, or affiliation claims

This rule applies to server entities, editorial pages, comparison tables, and all structured data (JSON-LD). Any schema property that would imply a fabricated value (e.g., aggregateRating,review, offers, certification) is omitted unless real evidence exists.

Evidence requirements

A claim is eligible for publication only when the Evidence Ledger contains a reference that satisfies:

  • Primary source — The reference points to the authoritative origin (repository, official docs, package registry, specification). Secondary sources (blog posts, aggregators, forums) are supplementary only.
  • Verifiable — A human or automated process can independently reach the same conclusion from the source.
  • Current — The source reflects the state of the system at or near the reviewedAt date.
  • Specific — The finding addresses the exact claim (e.g., "tool X accepts parameter Y" not "server has tools").

For server entities, at least one verified evidence reference is mandatory for indexable status. Unverified references (maintainer declarations) are recorded but do not satisfy the publication authority.

For editorial pages, factual claims about external systems (clients, servers, protocols, specifications) require ledger-backed evidence. Analysis, synthesis, and methodology explanations produced by MCPserver.in are labeled as editorial sources.

Best and recommendation methodology

MCPserver.in does not produce "best of" lists, top-N rankings, or scored leaderboards. The methodology for any recommendation or qualified-for statement:

  1. Define the use case — What task or workflow does the user need to accomplish?
  2. Identify candidate servers — Filter the indexable server registry by relevant tags/capabilities.
  3. Apply selection criteria — Documented capability match, transport fit, auth compatibility, read/write posture, maintenance signals.
  4. Evidence each criterion — Every criterion row in a comparison table cites a ledger finding.
  5. State limitations — Known gaps, unverified claims, and version-specific caveats are explicit.
  6. Publish the methodology — The comparison page links to /methodology and the relevant ledger entries.

Prohibited language: "best", "top", "#1", "highest rated", "most popular", "fastest", "recommended" without qualification. "Qualified for [use case] because [evidenced reason]" is the required framing.

Commercial independence

MCPserver.in has no commercial relationship with any MCP server maintainer, client vendor, or platform provider that influences:

  • Server eligibility or indexable status
  • Editorial coverage decisions
  • Comparison selection or outcomes
  • Recommendation language
  • Ledger findings or verification states

If a commercial relationship ever exists (sponsorship, partnership, affiliate), it will be disclosed on the affected page and in the ledger. The publication authority rules remain unchanged regardless of any commercial relationship.

Stale content handling

Freshness is tracked via the ledger's reviewedAtfield. The stale threshold:

  • Server entities: 90 days
  • Editorial pages: 180 days
  • Trust routes: 180 days

When an entry exceeds its threshold:

  1. The entry is flagged in the editorial queue.
  2. An editor reviews the underlying system (repository activity, releases, docs, domain status).
  3. If the system is unchanged: the ledger is re-verified, reviewedAt is updated, and the entry remains published.
  4. If the system has changed materially: the ledger is updated with new findings, reviewedAt is updated, and the page is regenerated.
  5. If the system is archived, deleted, or the domain expired: the entry moves to quarantine status and becomes non-indexable.

Correction process

Corrections follow the same process as described in /methodology:

  1. Error identified (internal review, reader report, maintainer contact).
  2. Ledger entry updated with corrected finding.
  3. reviewedAt updated to correction date.
  4. Correction note added: "Corrected [date]: [what was wrong] → [what is correct]. Source: [URL]."
  5. Affected pages regenerated on next build.
  6. If publication eligibility changes, sitemap and llms.txt regenerated.

To report an error, use the contact information in security.txt or the GitHub repository issue tracker linked from /about.