Trust Score
LightNow summarizes available trust evidence for an evaluated MCP server as a 0–100 score, a level and a set of evidence layers. Use the result to route a review, not as an automatic approval or guarantee of safe behavior.
Read the result in order
excellent, high, medium, low, unverified and unknown are
routing signals for the review.
A failed_critical layer overrides the aggregate and forces an
unverified result.
Find out whether the weak signal concerns identity, ownership, endpoint, source, reputation or vulnerabilities.
Stale evidence and a high-impact workflow require more review than a disposable personal experiment.
Do not derive the level from the number in client-side policy. Read the level returned by LightNow. This keeps automation aligned when the evaluation contract or thresholds evolve.
Evidence layers
| Layer | Question it helps answer |
|---|---|
| Publisher identity | Is the publisher identity coherent and attributable? |
| Domain verification | Does the owner control the claimed domain where that proof applies? |
| Repository verification | Does the owner control the referenced source repository? |
| Endpoint security | Is the remote endpoint reachable through an acceptable TLS and URL posture? |
| Source code | What source, license and provenance evidence is available? |
| Reputation | What maturity and activity signals are visible for the upstream project? |
| Vulnerability | Are known advisories associated with the evaluated source or package? |
| System blocklist | Does a critical rule require the result to be rejected? |
not_applicable means a layer has no relevant input for this server. It is
excluded from the weighted aggregate instead of lowering the score. A missing
or failed applicable layer is different and should remain visible in the
review.
How aggregation works
Several layers can have configured weights. LightNow normalizes the weighted sum across the layers that apply. This means the visible percentages are not a simple checklist that must add up to 100 before normalization.
The numeric score is useful for comparison. The layer status and evidence are what explain the decision.
Interpret the levels
| Level | Interpretation |
|---|---|
excellent or high | No critical failure is present and the available evidence is strong. Still confirm capabilities and data access for the intended workflow. |
medium or low | At least one relevant signal is weaker or incomplete. Inspect the layer and decide whether isolation or additional proof is sufficient. |
unverified | A critical failure or explicit unverified outcome requires investigation before rollout. |
unknown | The evaluation has not produced enough applicable data. Unknown is not the same as safe. |
Trust is contextual
The same server can be acceptable for a temporary personal test and unsuitable for an organization-wide default profile. Consider:
- which tools, resources and prompts it exposes,
- which local files or remote systems it can access,
- whether the server handles production or sensitive data,
- whether ownership and source evidence match your policy, and
- whether the evidence is fresh enough for the rollout decision.
Trust Score does not replace sandboxing, least privilege, secret scoping or an internal security review.
When to re-check
Review trust again when the server version, publisher, source repository, endpoint or vulnerability posture changes. Also re-check before promoting a server from a personal profile into an organization default.
- Ownership & Verification explains domain and repository ownership signals.
- Product tour places trust review in the path from discovery to runtime.