Trust score

LightNow calculates a 0–100 trust score for each MCP server version.

The score is designed to give platform teams a single, comparable signal across different servers and versions – so they can decide which MCP servers are safe to use in which contexts.

Internally, the trust score is derived from multiple layers of signals and updated over time as new information becomes available.

---

Why a trust score?

MCP servers can come from many different publishers and ecosystems:

• some are open source and maintained by well-known vendors,
• some are internal to your organization,
• others might be experimental or poorly maintained.

A plain “listed vs. unlisted” view is not enough. LightNow aims to give you:

• a single score for quick decisions (0–100), and
• a layered breakdown so you can see why a server has its score.

This combination enables policies such as:

• “Only allow servers with a trust score ≥ 70.”
• “Only allow servers with verified domain and repository ownership.”
• “Block servers with risky transports or missing ownership signals.”

---

Trust layers

The exact implementation may evolve, but conceptually LightNow considers several trust layers:

1. Identity & publisher

   • Who publishes this MCP server?
   • Is the publisher known and consistent across versions?
   • Is the reverse-DNS server name aligned with domains or repositories they control?

2. Ownership

   • Has the publisher proven control over relevant assets?
     • Domain verification (DNS TXT, /.well-known).
     • Repository verification (GitHub App installation, OIDC-based CI evidence, Sigstore in the future).
   • Are manifest URLs consistent with verified domains and repositories?

3. Security & integrity

   • Does the server manifest pass schema validation against the official MCP server schema?
   • Are transports considered safe (e.g. stdio, streamable-http) or potentially risky?
   • Are there cryptographic signatures or integrity proofs available (for example Cosign – planned)?

4. Reputation & runtime signals

   • How widely used is the server within the registry?
   • Have there been incidents, yanked versions or security advisories?
   • Are there policy overrides by tenant administrators (for example explicit allow/deny)?

Each layer contributes positively or negatively to the final score.

---

Score range and levels

The trust score is a numeric value in the range 0–100:

• Higher values mean higher confidence in the server version.
• Lower values indicate missing verification, poor signals or known issues.

To make this easier to interpret, LightNow maps the score to levels:

• Low trust – typically scores below a lower threshold (for example < 50).
• Medium trust – mid-range scores where some signals are present but not all.
• High trust – scores above a high threshold (for example ≥ 80).

The exact thresholds are configurable on the platform (see trust config) and are used consistently:

• in the dashboard cards (colored bar / indicator),
• in the server table view,
• and on the server detail page (circular trust indicator).

---

How the score is updated

The Registry-API and related services follow an event-driven model:

• When a new MCP server version is published, a capability scan requested event is emitted.
• Scanners and verification services process this version:
  • inspect capabilities (tools, resources, prompts),
  • validate the manifest against the MCP schema,
  • resolve ownership information and security signals.
• As results come in, the normalized server version representation and its trust attributes are updated.
• A recalculated trust score is written and exposed via the API.

This means:

• trust scores can improve over time as more signals become available,
• yanked or deprecated versions can have their trust scores reduced or marked accordingly.

---

Using trust scores in the UI

In the LightNow UI you will see trust scores in several places:

• On the Servers dashboard:
  • each card shows a colored trust bar with numeric score,
  • table rows show trust level and score.
• On the Server detail page:
  • a circular indicator with the exact score,
  • a breakdown by trust layers (identity, ownership, security, reputation),
  • additional context such as verification status and capabilities.

The visual treatment (colors, icons, labels) follows the configured trust thresholds.

---

Using trust scores in policies

Tenants can use trust scores and layers in their governance:

• Require a minimum trust score for servers to be available to users.
• Require verified domains and repositories for certain environments.
• Allow internal servers with lower scores, but not external ones.
• Exclude certain transports or publishers regardless of score.

LightNow is designed so that the trust score and its components are:

• transparent – visible on detail pages and via API,
• consistent – same thresholds applied across views,
• configurable – thresholds and weighting can be adapted over time.

For more details on configuration and internals, see the internal Trust Evaluation Architecture documentation and the API reference.