349 non-MCP Profiles: Removing Non-MCP Entries Is Part of Registry Quality
349 detailed profile rows are classified as non-MCP. Separating lookalike entries from real MCP servers prevents false adoption signals.
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
Discovery sources mix documentation, directories, examples, broken endpoints, and non-MCP APIs. Leaving them in the candidate pool lowers adoption quality.
Key Findings
- 349 detailed profile rows are classified as non-MCP. Separating lookalike entries from real MCP servers prevents false adoption signals.
- 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-07 |
| 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 |
|---|---|---|
| non-MCP profiles | 349 | Candidate not treated as an MCP server |
| Remote endpoint not MCP | 136 | Remote endpoint that did not speak MCP protocol |
| Reference-only targets | 632 | Reference-only candidate whose implementation did not close |
What We Observed
Discovery sources mix documentation, directories, examples, broken endpoints, and non-MCP APIs. Leaving them in the candidate pool lowers adoption quality. This lens matters because MCP servers are not just plugins; they are bundles of authority exposed to an AI agent.
Practical Reading
MCP candidate management should include exclusion with reasons, not just accumulation. 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
MCP candidate management should include exclusion with reasons, not just accumulation. 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.