Five Signals to Review Weekly in MCP Security
Using 20,629 public Registry entries and 11,627 profile-evidence rows, weekly MCP security review should track more than total count: status distribution, growing capabilities, source/auth gaps, and runtime boundary.
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
Weekly MCP security review needs more than a count refresh. Status distribution, growing capabilities, source/auth gaps, and runtime boundary show what should change in the adoption review.
Key Findings
- The 20,629 public Registry entries and 11,627 profile-evidence rows show that weekly review should track more than total count.
- The 20,629 public Registry entries and 11,627 profile-evidence rows answer different questions and should not be mixed casually.
- The observation is an adoption input, not a final approval for a specific environment.
- Counts are snapshot evidence, so adoption review should check the observation date before treating the number as current state.
Dataset
| Item | Value |
|---|---|
| Article date | 2026-06-19 |
| 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 |
|---|---|---|
| Public Registry entries | 20,629 | Population for status-distribution review |
| Action rows | 20,210 | Size of the review/action population |
| Detailed profile evidence | 11,627 | Profile-evidence population for deeper analysis |
What We Observed
The 20,629-entry public Registry shows why MCP servers should not be treated as a simple plugin list. They are bundles of authority exposed to an AI agent. Weekly review should track not only total count, but WARN/NEED_REVIEW/RESTRICT mix, growing capabilities, source/auth gaps, and local-versus-remote runtime boundary.
Practical Reading
Each weekly review should pick the highest-impact change from metric movement, category shift, growing capability, or unresolved evidence, then update the adoption rule or allow/restrict list. Review should record execution location, destinations, data touched, and unresolved evidence, not only the server name or README.
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.
Conclusion
Weekly review should separate status distribution, capability movement, source/auth gaps, and runtime boundary. Keeping this evidence in the intake record makes the review repeatable across teams and deployments.
MCP Guard continuously turns public Registry and profile evidence into adoption-review signals for MCP security teams.