20,629 Inspected MCP Entries: Five Adoption Review Priorities
Out of 20,629 public Registry entries, only 419 were PASS and 20,210 were in WARN, NEED_REVIEW, RESTRICT, or BLOCK. MCP adoption review should separate runtime boundary, provenance, authentication, mutation authority, and unresolved evidence instead of treating review as a simple allow/block decision.
Terminology
| Term | Meaning |
|---|---|
| Public Registry | Inspected MCP candidates searchable in the public Registry |
| Review/action rows | Entries in WARN, NEED_REVIEW, RESTRICT, or BLOCK that require reasoned adoption review |
| Profile evidence | Aggregate evidence used to interpret runtime, source, auth, and capability patterns |
| PASS | Public snapshot state with no prominent caution, restriction, or unresolved-review reason |
Lead
In MCP Guard's public Registry, only 419 of 20,629 inspected MCP entries were PASS. That does not mean "almost everything is malicious." It means most MCP adoption decisions are review problems: teams need to read the reason, define the boundary, and decide what authority the MCP server should get.
Key Findings
- 20,210 of 20,629 public Registry entries, or 98%, were review/action rows.
- The snapshot contained 419 PASS, 9,925 WARN, 5,394 NEED_REVIEW, 4,881 RESTRICT, and 10 BLOCK entries.
- Profile evidence separates several adoption-review priorities: local process execution, command/code execution, external mutation, file mutation, provenance gaps, and credential access.
- The practical takeaway is not which MCP server to fear; it is which authority, boundary, and unresolved-evidence checks to add before adoption.
Dataset
| Item | Value |
|---|---|
| Article date | 2026-06-21 |
| Public Registry snapshot | 20,629 entries, synced 2026-06-06T01:17:38.963Z |
| Detailed profile evidence | 11,627 rows, generated 2026-05-20/21 |
| Public disclosure level | Aggregates, distributions, anonymized observations, and practical interpretation |
Status Distribution
| Status | Rows | Adoption reading |
|---|---|---|
| PASS | 419 | Fewer prominent warnings or unresolved-review reasons in the public snapshot. Environment-specific review still matters. |
| WARN | 9,925 | Not an automatic rejection, but the reason and authority boundary should be reviewed. |
| NEED_REVIEW | 5,394 | Source, auth, runtime, dependency, or other evidence is not complete enough for a final adoption decision. |
| RESTRICT | 4,881 | Use only with explicit limits on authority, data, network, or operating scope. |
| BLOCK | 10 | Strong public-snapshot reason to stop adoption by default. |
Five Priorities Before Adoption
1. Runtime Boundary
Detailed profile evidence includes 10,335 local-process profiles and 10,070 stdio profiles. Treating MCP only as a remote API integration misses this. For local MCP servers, teams need to review working directory access, environment variables, OS permissions, dependency installation, and network destinations.
2. Command And Code Execution
Command-or-code execution capability appeared in 2,858 profiles. This can be legitimate for developer tooling, but it means the review must ask what input can trigger execution, what output can leave the machine, and what state remains after failure.
3. External Mutation And File Mutation
External-service or remote-state mutation appeared in 2,555 profiles, and file-mutation capability appeared in 1,425. Read-only MCP servers and mutation-capable MCP servers should not share the same approval path. Mutation-capable servers need audit logs, scope limits, rollback expectations, and least-privilege credentials.
4. Source And Provenance Gaps
Source-resolution gaps appeared in 2,005 profiles. MCP adoption should not rely on name, README, or package metadata alone. Repository, distribution source, ownership, update history, and dependencies need to be checked, especially when provenance does not close cleanly.
5. Authentication And Credential Boundary
Credential-access signals appeared in 487 profiles. That is a smaller slice of the total, but it carries high operational weight. When an MCP server handles API keys, OAuth, sessions, or local environment secrets, teams need explicit ownership, scope, rotation, audit, and agent-visibility decisions.
Practical Reading
The 20,629-entry summary shows that MCP security is not only about finding bad MCP servers. A practical intake record should separate at least five fields:
- Runtime: local process or remote service
- Authority: command execution, file mutation, external mutation, or credential access
- Provenance: repository, package, distribution source, and owner
- Destination: service, network boundary, and data flow
- Unresolved evidence: whether NEED_REVIEW reasons are acceptable for the deployment
Limits
- The evidence uses public aggregate data and anonymized observations, not internal detection mechanics.
- Counts are snapshot values and will change as the Registry updates.
- This is not a claim that any named MCP server is safe or unsafe.
- PASS is not a universal safety guarantee. Deployment-specific authority, data, and network boundaries can still require additional review.
Conclusion
The strongest finding from the 20,629-entry public Registry is that most MCP adoption decisions are not simple allow/block decisions. Teams get better review quality by separating runtime boundary, mutation authority, provenance, authentication, and unresolved evidence before an MCP server is allowed into an agent workflow.
MCP Guard continuously turns public Registry and profile evidence into adoption-review signals for MCP security teams.