MCP Official and Verified Statistics 2026: Only 16% Carry Both Signals

Trust badges are the exception, not the default: 85 of 520 MCPtrove listings are both official and verified, while 331 carry neither signal.

Contents

• Methodology and limitations
• Main findings
• Interpretation
• Practical decision guidance
• How to cite or download the data
• Related MCPtrove research
• FAQ

Methodology and limitations

This analysis uses a 520-listing snapshot from the MCPtrove directory. It describes what was present in that directory snapshot, not the complete MCP ecosystem. MCPtrove did not survey users, and this page does not measure every MCP server in existence.

MCPtrove classifies listings using separate normalized directory fields for official and verified status. The groups below distinguish listings carrying both labels, only the official label, only the verified label, or neither label. The official and verified totals overlap because a listing can carry both.

Where this page refers to category, authentication, transport, official, or verified status, those are MCPtrove-normalized directory fields. They are useful classification signals, but they are not protocol guarantees, security audits, uptime promises, or endorsements.

A single listing can expose many tools. Accordingly, the normalized tool count is a property of a listing’s declared capability surface, not a measure of how frequently users invoke those tools or how valuable they are. GitHub stars are repository-level context, and stars may repeat when multiple listings share the same repository.

The figures are descriptive. They should not be read as evidence that official or verified status causes higher star counts, broader tool coverage, or any particular authentication or transport choice.

Main findings

The directory grouping is:

Across the directory, the official total is 149, while the verified total is 125. The difference between those totals reinforces that the labels capture distinct provenance dimensions rather than a single trust scale.

The most prominent result is the size of the neither group: 331 listings carry neither signal. By comparison, 85 carry both. The page title’s 16% is therefore a useful shorthand for the limited reach of the combined badge state within this snapshot.

The GitHub-star medians show a clear descriptive ordering. Listings carrying both labels have a median of 730 stars. The verified-only median is 590, followed by official-only at 215 and neither at 174.

Tool-count medians are much closer. Both the official-and-verified group and the official-only group have a median of 10 normalized tools. The verified-only median is 11, while the neither group is again 10.

The authentication and transport counts are:

These are directory counts, not security scores. An OAuth label does not establish that scopes are narrowly designed, and an HTTP label does not establish that deployment, authentication, or network exposure is safe.

Interpretation

The practical lesson is not that badges are meaningless. They are useful provenance shortcuts. They can help a directory visitor decide which listings deserve an earlier look, especially when the repository relationship or ownership history is otherwise difficult to establish.

But provenance and capability are different questions. The identical median tool count for the both, official-only, and neither groups—each at 10—is a useful reminder that a badge does not automatically describe breadth. The verified-only group’s median of 11 also does not prove that verification produces broader capability.

The star medians deserve the same discipline. The both group’s 730-star median is higher than the neither group’s 174, but the snapshot cannot tell us why. A relationship with an official organization, stronger discoverability, repository age, community interest, or other factors could contribute. The figures show association inside this directory view, not causation.

The safest editorial position is therefore straightforward: use official and verified status to reduce provenance uncertainty, then continue with ordinary security judgment. A badge can help answer “where did this listing come from?” It cannot answer “what will this tool do in my environment?” or “what access should I grant?”

Practical decision guidance

Start with the official MCP collection when provenance is your first filter. Use Best MCP Servers when you want a broader shortlist, and use Config Doctor when you need help reviewing or correcting an MCP configuration.

For any candidate, inspect the complete normalized tool list. Because a single listing can expose many tools, review the intended operations individually rather than treating the listing as a single indivisible permission.

Keep least privilege at the center of the decision. Grant only the credentials, filesystem access, network access, and scopes the intended workflow requires. Read the repository and configuration carefully, perform code review where possible, verify the requested authentication scopes, and test the runtime behavior in a controlled environment.

If a listing is both official and verified, treat that as a reason to investigate sooner, not as permission to skip those checks. If it has only one signal, identify what the signal establishes and what remains unknown. If it has neither, do not treat that alone as a rejection; treat it as a reason to demand stronger independent evidence before deployment.

The OAuth and HTTP counts can help you understand how listings are distributed across the snapshot, but they should not decide whether a particular server is safe. Security depends on implementation, configuration, credentials, scope design, isolation, maintenance, and runtime behavior.

How to cite or download the data

Download the raw CSV to inspect the underlying group assignments and directory fields. When using these figures in your own analysis, preserve the distinction between listing-level observations and repository-level signals, especially where repositories are shared.

For a reproducible citation, copy the following:

MCPtrove. MCP Official and Verified Statistics 2026: Only 16% Carry Both Signals. https://mcptrove.com/research/mcp-official-verified-statistics. Accessed September 23, 2026.

Related MCPtrove research

For a broader view of whether projects remain active, read MCP Maintenance Activity Statistics. For context on repository popularity, see MCP GitHub Stars Benchmark. For the security principles behind this page’s recommendation, read MCP Security: What Actually Matters.

FAQ

Does official and verified mean an MCP server is safe?

No. These are separate MCPtrove-normalized directory fields. They are provenance shortcuts, not security audits, protocol guarantees, uptime promises, or endorsements. Continue with least-privilege configuration, code review, scope checks, and runtime testing.

Why is the both group’s median tool count not higher?

The both group has a median of 10 normalized tools, the same as the official-only and neither groups. The verified-only median is 11. This shows that the labels describe provenance, not necessarily capability breadth.

Should I reject listings with neither signal?

Not automatically. The neither group contains 331 listings in this snapshot, but the absence of a directory signal is not itself a security verdict. Inspect the repository, documentation, requested permissions, authentication design, transport, maintenance, and runtime behavior.

Where can I download the underlying data?

The complete raw CSV contains the data used for this page.