How scoring works
Every report in the registry comes from an analysis of the code at a specific commit. This page explains what the numbers and labels mean, and what they do not.
Trust score
A score from 0 to 100. Higher means more trusted: fewer and less severe issues relative to what the component can do. Each score falls into a tier.
| Tier | Score | What it means |
|---|---|---|
| High trust | 85–100 | Few or minor issues for what the component can do. |
| Moderate trust | 65–84 | Some issues worth reviewing before you rely on it. |
| Low trust | 40–64 | Issues that should be fixed or contained before production use. |
| Very low trust | 0–39 | Serious issues. Review the fixes before connecting it to anything that matters. |
Likely range
Each score comes with the range it most likely falls in. A wide range means the analysis is less certain. Read a score of 40 with a range of 12–68 as “somewhere in that span, most likely near 40.”
What pulled the score down
Each report lists the rules whose findings lowered the score most, with their severity. Each links to its fix.
Severity, as assessed for each repository
Every rule has a fixed severity: Critical, High, Medium or Low. The registry shows the severity assessed for the repository in front of you, which can be lower than the rule’s default when the context reduces the risk. When it differs, the report shows both, with the reason.
- Declared behavior. The component openly states that it does this, so it is a capability to weigh, not a hidden defect.
- Local transport only. The issue is only reachable when the server runs on a local transport, which narrows who can trigger it.
- Mitigation present. The code already contains a control that limits the impact.
- Confirmed exploitable. The analysis confirmed a working path, so no reduction applies.
Results
Each rule produces one result for each component it applies to.
| Issue found | The code fails the rule. The report shows where, why it matters and how to fix it. |
| Passed | The code meets the rule. |
| Does not apply | The rule does not apply, for example a remote-transport rule on a server that only runs locally. |
| Could not determine | The analysis could not reach a conclusion. Treat it as worth a look. |
What its tools can do
Every tool a component exposes is classified by what it lets an agent do. A tool can have several classes.
| Run code or commands | Executes processes, scripts or shell commands. |
| Delete or overwrite data | Actions that remove or replace data. |
| Use secrets and credentials | Reads or handles keys, tokens or passwords. |
| Manage identities and access | Creates or changes users, roles or permissions. |
| Change settings | Alters configuration of a system or account. |
| Reach any network address | Fetches or connects to arbitrary hosts. |
| Returns untrusted content | Returns content from outside sources, such as web pages or files, that could carry instructions an agent might act on. |
| Spend money or metered resources | Calls that cost money or use paid quota. |
| Post or message on your behalf | Publishes or sends messages as you. |
| Create or change data | Writes, updates or creates records and files. |
| Read data | Looks up or reads information without changing it. |
The rules (34)
Rules are grouped by what they apply to. A repository is checked against the common and guardrail rules once, and each MCP server or skill inside it against the rules for its type.
MCP server rules (11)
Applies to: Each MCP server in a repository
| Rule | Name |
|---|---|
| ATR-M0001 | Tool Definition Integrity & Versioning (ETDI-style) |
| ATR-M0002 | Unrestricted Tool Permissions (Overprivileged Tools) |
| ATR-M0003 | CORS / Origin / Host Validation (DNS Rebinding Defense) |
| ATR-M0004 | Binding to 0.0.0.0 Without Auth/TLS |
| ATR-M0005 | OAuth 2.1 + PKCE Correctness (MCP Authorization) |
| ATR-M0006 | Tool Name Collision / Spoofing |
| ATR-M0007 | Prompt/Metadata Injection in Tool Descriptions |
| ATR-M0008 | CORS Misuse: Wildcard with Credentials |
| ATR-M0009 | Transport Security: TLS Everywhere (Remote) |
| ATR-M0010 | No Authentication or Authorization Checks (General) |
| ATR-M0011 | OAuth Proxy Per-Client Consent (Confused Deputy Defense) |
Skill rules (8)
Applies to: Each skill or plugin in a repository
| Rule | Name |
|---|---|
| ATR-P0001 | Capability Transparency: Declared Purpose vs. Actual Behavior (Shadow Features) |
| ATR-P0002 | Consent Suppression and Guardrail / Human-in-the-Loop Subversion via Trusted Instructions |
| ATR-P0003 | Host-Credential and Conversation-Context Harvesting and Exfiltration |
| ATR-P0004 | Format-Native Out-of-Band Execution and Host Control-Plane Persistence |
| ATR-P0005 | Over-Declared / Over-Privileged Artifact Manifest Scope |
| ATR-P0006 | Injection and Concealed Directives in Skill/Plugin Manifest and Instruction Text |
| ATR-P0007 | Skill/Plugin Package Provenance, Integrity, and Post-Approval Mutation (Rug-Pull) |
| ATR-P0008 | Skill/Plugin Impersonation, Typosquatting & Publisher Spoofing |
Common rules (14)
Applies to: The repository as a whole
| Rule | Name |
|---|---|
| ATR-C0001 | Unrestricted Network Fetch / SSRF |
| ATR-C0002 | Static Secrets |
| ATR-C0003 | Runtime Command Injection via Process Execution |
| ATR-C0004 | DoS Protections: Timeouts, Concurrency, Streaming Limits |
| ATR-C0005 | Logging Hygiene (No Secrets/PII/Tokens) & Audit Trail |
| ATR-C0006 | Container/Runtime Hardening |
| ATR-C0007 | Dependency Risk & Supply Chain |
| ATR-C0008 | Missing or Inadequate Input Validation |
| ATR-C0009 | Insecure Deserialization |
| ATR-C0010 | Lack of Output Encoding/Sanitization |
| ATR-C0011 | Path Traversal & Symlink Bypass (Filesystem Tools) |
| ATR-C0012 | Denial of Wallet / Cost Controls |
| ATR-C0013 | Tool Output Sanitization & Injection Containment |
| ATR-C0014 | CI/CD Workflow Script Injection |
Guardrail rules (1)
Applies to: The repository as a whole
| Rule | Name |
|---|---|
| ATR-R0001 | Weaponization: Malicious-Purpose Artifact (Offensive Capability by Design) |
Scan dates
Every report shows the date it was scanned and the commit it analyzed. Code changes after that date are not reflected until the repository is scanned again.
Questions
What is the Agentic Trust Registry?
BlueRock’s registry of assessed MCP servers, agents, and skills. Each report comes from an analysis of the code at a specific commit and shows what the component can do, what risks were found, and what to fix.
What does the trust score mean?
A score from 0 to 100. Higher means more trusted: fewer and less severe issues relative to what the component can do. Each score comes with the range it most likely falls in, and a wide range means the analysis is less certain.
Why can a finding’s severity differ from the rule’s default?
The registry shows the severity assessed for the repository in front of you, which can be lower than the rule’s default when the context reduces the risk, for example declared behavior, a local transport only, or a mitigation already in the code. When it differs, the report shows both, with the reason.
What does a report show for each issue?
The exact file and lines, the code, why it matters, and the recommended fix, with a fix prompt you can paste into your coding agent.
Is a trust score a certification?
No. A trust score is an assessment of the code at one point in time, not a guarantee or a certification. Code changes after the scan date are not reflected until the repository is scanned again.
Can I scan my own MCP server, agent, or skill?
Yes. Submit a public or private MCP server, agent, or skill at bluerock.io/scan. Your first scan is free.
What a score is not
A trust score is an assessment of the code at one point in time, not a guarantee or a certification. It cannot see how a component is configured where you run it, or what your agent will actually do with it. That is what runtime observability and guardrails are for.