Why 20,210 MCP Registry Rows Need Review, Not Just Blocking
Out of 20,629 public Registry entries, 20,210 fall into WARN, NEED_REVIEW, RESTRICT, or BLOCK. The key lesson is that MCP review needs a workflow for uncertainty, not only a blocklist.
Terminology
| Term | Meaning |
|---|---|
| Public Registry | Inspected MCP candidates searchable in the public Registry |
| Profile evidence | Inspection-profile aggregates used to interpret public candidates in more depth |
| Review/action rows | Entries in WARN, NEED_REVIEW, RESTRICT, or BLOCK that require reasoned adoption review |
Lead
Security review is not only about finding something bad and stopping it. MCP introduces many intermediate states: broad authority, incomplete evidence, missing configuration, unclear source provenance, or runtime behavior that depends on credentials.
Key Findings
- 20,210 Registry rows, or 98%, currently require some form of review or action.
- WARN accounts for 9,925 rows, NEED_REVIEW for 5,394, and RESTRICT for 4,881.
- BLOCK accounts for 10 rows, so hard-stop findings are a small part of the operational picture.
- The center of MCP review is evidence-based prioritization, not a binary allow/block habit.
Dataset
| Item | Value |
|---|---|
| Article date | 2026-04-14 |
| 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 operational interpretation |
Observed Metrics
| Metric | Value | Meaning |
|---|---|---|
| WARN | 9,925 | Candidates that require caution or constraints |
| NEED_REVIEW | 5,394 | Candidates needing additional evidence |
| RESTRICT | 4,881 | Candidates leaning toward restriction |
| BLOCK | 10 | Strong stop candidates |
What We Observed
A small BLOCK count should not be read as a broad safety claim. In MCP, many decisions are about whether a capability should be allowed in a particular workflow, not whether a server is universally malicious. The size of WARN and NEED_REVIEW shows that review spans configuration, provenance, authentication, source reachability, and data movement, not only classic exploit patterns.
Practical Reading
A practical adoption flow can treat BLOCK as an automatic stop, RESTRICT as a security approval queue, WARN as constrained use, and NEED_REVIEW as an evidence-gathering state. The point is not to inspect every candidate at the same depth. Teams should combine Registry state with business impact and data sensitivity to choose the review order.
Limits
- Registry state reflects public observation and does not include a customer environment's exact permissions or data classification.
- WARN and NEED_REVIEW do not prove a successful attack.
- Counts are snapshot values and will change as the Registry is updated.
Conclusion
The operational value of MCP security is not only catching a few bad entries, but making tens of thousands of uncertain entries reviewable.
MCP Guard continuously turns public Registry and profile evidence into adoption-review signals for MCP security teams.