How ToolRepute evaluates results

ToolRepute indexes AI tools and MCP integrations, analyzes available source without executing it, applies publication reliability checks, and manually reviews eligible results before public display.

The current database uses registry and source metadata, public repository locations, package declarations, and remote-endpoint metadata when those fields are present. A registry record identifies an integration; it is not a security endorsement.

Scanner V6 checks supported, available repository source for these bounded signal groups:

Manifests and source coverage

Recognized build manifests, readable metadata, scanned files and bytes, and truncation signals.

Dependencies

Direct URLs, local paths, unpinned versions, and custom package sources declared in supported manifests.

Install and execution mechanisms

Lifecycle scripts, install or bootstrap files, shell-execution patterns, and declared command-line entry points.

Executable and binary artifacts

Tracked executable permissions and files whose extensions indicate binary or executable artifacts.

Secret-like values

Patterns resembling private keys, service tokens, access keys, or hard-coded credential-like literals.

Obfuscation signals

Encoded-content and dynamic-evaluation patterns that can make source harder to review.

• Runtime behavior or live network activity.
• Hosted remote service code that is not present in the analyzed source.
• External systems and dependencies outside the inspected repository scope.
• Future versions or later source changes.
• Full malware behavior: binaries and repository code are not executed in a sandbox.

A finding is a detected security-relevant signal from static analysis. Each published finding has a stable code, severity, category, summary, explanation of why it matters, recommended checks, a sanitized snippet when available, and a limitation. Raw credential snippets, private metadata and internal reviewer notes are withheld. A finding is not proof of malicious behavior, a confirmed vulnerability, exploit, malware, compromise, or malicious intent.

No findings means the scanner did not detect matching signals under the current rules and available source coverage. No findings does not mean the tool is safe, secure, or free of issues.

Low, Medium, High, and Critical describe the severity of detected static-analysis signals. They are not a probability that a tool is malicious, a trust score, or a guarantee of exploitability.

Low

A lower-severity signal that still provides useful review context.

Medium

A signal that deserves closer inspection before use.

High

A serious detected signal with potentially significant security impact.

Critical

The highest-severity detected signal and a strong reason for immediate investigation.

High and Critical findings can be published when the underlying assessment is sufficiently reliable and the result is approved for publication. Publishing the signal makes the evidence visible; it is not a safety endorsement and does not confirm malicious behavior.

Coverage describes whether the available source was sufficient for the current publication checks. A completed run can still have insufficient source coverage when the repository contains only metadata, documentation, configuration, or too little implementation evidence.

Sufficient

The run met the current publication coverage thresholds.

Insufficient source

The run completed, but the available source or manifest coverage was not enough for reliable publication.

Limited

The run was truncated or otherwise limited, so its result is withheld.

Not applicable

Coverage cannot be assessed because no completed scan result is available.

The conceptual flow is registry → candidate → scan → findings → reliability checks → manual review → publication. Publication eligibility is based on the latest primary-source run across every run status, so a newer failed run supersedes an older published result.

Reviewed or published means the scan result passed ToolRepute's reliability checks and manual publication workflow. Approved for publication is not a safety endorsement of the tool. Risk and publication reliability are evaluated separately. Review freshness is shown separately: historical decisions are retained, while a page that has not checked upstream HEAD cannot establish current-source approval.

• False positive: a rule can flag harmless test, example, reference, or intentional code that still deserves context.
• False negative: an issue can exist without matching the current scanner rules.
• Static analysis cannot prove safety and does not observe runtime behavior, hosted backend or infrastructure behavior, or publisher trustworthiness. It does not guarantee the absence of vulnerabilities or that external dependencies remain unchanged.
• Incomplete, metadata-only, hosted, or remote source can limit what the result represents.
• A result reflects the displayed source, commit, scanner version, scan time, and review state. A future version or later source changes may behave differently.