DEV Community: Cakra Budiman

The state of MCP servers and agent skills, November 2026

Cakra Budiman — Sat, 14 Nov 2026 11:09:18 +0000

Disclosure: I run HostedMCP, an open directory of MCP servers and agent skills. These numbers come from its database; the full report with methodology is on hostedmcp.org.

Most writing about the size of the MCP ecosystem quotes one directory's count, or a curated list of a few thousand repositories. We run a catalog that tries to see everything: the official MCP Registry, GitHub, npm and PyPI for servers, and GitHub for agent skills and plugin marketplaces. This report is what that catalog held on 14 November 2026, counted straight from the database.

Every number below is a measurement, not an estimate. Where a figure depends on a choice we made, such as which repositories count as skills, the methodology section at the end says so.

How big the ecosystem is

	Count on 14 Nov 2026
Active MCP servers	118,434
of which listed in the official MCP Registry	62,952
of which pass our bar for an indexed page	28,440
Agent skills (folders with a SKILL.md)	52,147
GitHub repositories those skills come from	3,339
Claude Code plugins	4,818
Plugin marketplaces they come from	1,142

Two numbers here are worth a second look. More than half of all servers now come through the official MCP Registry, which only launched in 2025. And fewer than a quarter of servers make it to an indexed page: the rest have no stars, no usable description, or come from publishers that post thousands of near-identical entries. We flag 13,357 servers from such bulk publishers.

Skills are concentrated differently. 52,147 skills come from only 3,339 repositories, about 16 per repository, because collections such as Anthropic's own and the large community libraries hold hundreds or thousands each.

Attention: a tall head and a very long tail

Here is every active server by the star count of its repository; servers without a public repository count as zero.

Stars	Servers	Share of servers	Share of all stars
0	75,507	63.8%	0%
1 to 9	31,182	26.3%	1.4%
10 to 99	8,856	7.5%	4.5%
100 to 999	2,324	2.0%	11.0%
1,000 to 9,999	473	0.4%	23.4%
10,000 and more	92	0.08%	59.8%

Counting each repository once, 86,922 of them, the star Gini coefficient is 0.984. The median repository has zero stars, 97% have fewer than 100, and the top 1% hold 87.8% of every star in the catalog.

Analyses built on curated catalogs of around 12,500 repositories have reported a Gini near 0.87 and described a missing middle. With the full long tail included, the picture is starker still: it is less a missing middle than a near-empty everything except the very top. Most of the tail is not abandoned work, either. 77,578 servers, about two thirds, were pushed to in the last six months. They are small, recent and unnoticed.

Skill repositories are less extreme, partly because we only ingest skill repositories with at least five stars. Across 3,339 of them the Gini is 0.960, the median is 19 stars, and the top 1% hold 73.2% of stars.

Local or remote

The transport is known for 63,847 servers:

Transport	Servers	Share
Remote only (hosted URL)	38,223	59.9%
Local only (stdio)	20,709	32.4%
Both	4,915	7.7%

Remote has overtaken local. When MCP launched in November 2024, servers were processes you ran on your own machine; today most entries, especially in the MCP Registry, are hosted endpoints you connect to by URL. For users that means less to install and more trust placed in whoever runs the endpoint.

Authentication

We could determine how a server authenticates for 50,247 of them:

Auth	Servers	Share of known
API key or token	18,728	37.3%
None	18,607	37.0%
More than one method	10,521	20.9%
OAuth	2,391	4.8%

OAuth is the authorization method the MCP specification defines for remote servers, and the one that lets a user grant and revoke access without pasting a secret into a config file. Fewer than one in twenty servers use it. API keys in environment variables remain the default, which is why so many setup guides ask you to put a token in a JSON file.

Licenses

MIT dominates with 53,950 servers (45.6%), followed by Apache-2.0 with 8,623 and AGPL-3.0 with 1,612. But 52,226 servers, 44.1%, name no license at all. Without one, nobody else has the right to copy or modify the code, whatever the repository looks like. Among skills, 6,853 of 52,147 (13.1%) carry no license.

How many tools a server exposes

For 14,429 servers we know the exact tool list:

Tools	Servers
1 to 5	4,012
6 to 15	6,416
16 to 40	2,977
41 or more	1,024

The typical server exposes between 6 and 15 tools. The 1,024 servers with 41 or more matter for a different reason: every tool definition is sent to the model with each request, and in our own measurements a large server's definitions alone can run past 100 KB.

What the checks found

We scan servers and skills weekly with automated checks that read public data: the repository, the license, OpenSSF Scorecard, package provenance, known advisories in OSV, package names that imitate popular ones, and the text a model will read, looking for instructions aimed at it. Nothing is executed. On 14 November 2026, 15,380 servers and 7,500 skills had a recent report.

Servers (15,380 scanned):

Finding	Servers	Severity
Instructions aimed at the model in tool descriptions or README	97	high
Package name one edit away from a popular package	55	high
Dependency with a critical advisory	36	high
Package names a different repository as its source	114	medium
Remote endpoint did not answer the MCP handshake	130	medium
No license, or not OSI-approved	1,113	low

About 1.2% of scanned servers carry at least one high-severity finding. That is a small share and a real number: up to 188 servers that an agent could be pointed at today. Each finding links to its evidence on the server's checks report.

Skills (7,500 scanned):

Finding	Skills	Severity
`allowed-tools` lets the agent run shell commands without asking	669	medium
Instructions aimed at the model in SKILL.md	50	high
Scripts that download and run code, or send credentials out	16	high
No license, or not OSI-approved	806	low

The skill finding that stands out is not the rare malicious script but the common shortcut: almost one skill in eleven pre-approves shell access, so the agent can run commands without asking the user. Usually that is convenience, not malice. It is still the setting that turns a bad instruction into a bad command.

How much we could check. Coverage is uneven. 31.7% of scanned servers could be checked on fewer than 60 of our 100 points, mostly because they publish no package, so there is no provenance, advisory or typosquat check to run. OpenSSF Scorecard results existed for only 163 of the 8,360 servers where that check ran. Until 14 November our score divided by the points we could check, which let a server checked on 35 points show 100/100; scores now never count on fewer than 60 points. 10,327 servers meet our Verified rule.

What this means if you use MCP

Stars tell you little below the top. With a median of zero, most servers have no social proof at all. Read the repository, the license and the checks report instead.
Prefer servers that ask for less. OAuth over a pasted token, read-only modes where offered, and skills that do not pre-approve shell access.
Remote is convenient and is trust. A hosted endpoint updates itself and needs nothing installed, and runs code you cannot see.
A license is not a formality. Nearly half of servers have none, which matters the moment you fork or ship one inside a product.

Methodology and limits

Date. All numbers come from the HostedMCP database on 14 November 2026. The catalog changes daily.
Servers. Active servers from the MCP Registry, GitHub search, npm and PyPI, after merging duplicates of the same package or repository. Star figures cover the 95,967 servers that link a repository; distribution tables use distinct repository URLs.
Skills. Folders containing a SKILL.md in public GitHub repositories with at least five stars. Repositories below that threshold are not ingested, so skill star figures start higher than server figures.
Transport, auth and tool counts come from registry metadata, package manifests and, for tool lists, servers that publish them. Unknown values are left out of the shares, not counted as negatives.
Checks read public data and the files an agent would read. They do not run code and are not a security audit. A finding is a pattern match with evidence, and a few may be false positives; the report for each listing shows exactly what was matched.

The full catalog, with every server's checks report, is at hostedmcp.org/servers, and skills at hostedmcp.org/skills.

The build flag that made our encryption 11 slower (and no one noticed for months)

Cakra Budiman — Wed, 12 Aug 2026 09:52:43 +0000

Shipping one Rust crypto core to five platforms with Flutter — and the cargokit gotcha that silently disabled hardware AES in every release build.
Users kept telling us transfers were slow. Our benchmarks kept telling us they were fast. Both were right — and the gap between those two sentences cost us months.

This is a story about shipping one Rust cryptography core to five platforms from a Flutter app, and about the single most instructive bug we hit doing it: a build flag that quietly turned hardware-accelerated AES off in every release build we shipped, while every build we benchmarked had it on.

The setup

I build BIShare, an open-source AirDrop-style app: direct device-to-device file transfer between iPhone, Android, macOS, Windows, and Linux. MIT licensed, Flutter UI, Rust core.

The architecture decision that matters for this story: all cryptography and protocol framing lives in a single Rust crate, bridged into Dart with flutter_rust_bridge. X25519 for key agreement, AES-256-GCM for the data path — implemented once, reviewed once, shipped to all five platforms. The Dart side never touches key material.

On paper this is the clean version of the diagram. One implementation instead of five means one place for bugs instead of five — which is true, and which is exactly why the bug that follows was so effective: we shipped it everywhere, identically.

The symptom

Local-network transfers should saturate Wi-Fi. Our release-build benchmarks on real devices showed 40–50 MB/s on ordinary Wi-Fi 5 hardware — a 1 GB video in about 25 seconds. That's the whole pitch of skipping the cloud.

But App Store users reported transfers crawling at about 2 MB/s. Twenty times slower. Same app, same network conditions, same code — allegedly.

We did the usual rounds: network path, buffer sizes, the Dart/native boundary, thermal throttling. Everything checked out. The transfer pipeline was fine. The cipher was not.

The cause

Modern ARM chips have dedicated AES instructions. With them, AES-256-GCM encrypts multiple gigabytes per second and is never your bottleneck. Without them, the same cipher falls back to a software implementation that is — on the hardware we measured — about 11× slower. Slow enough that encryption, of all things, becomes the ceiling on your transfer speed.

In Rust, enabling those instructions for aarch64 targets took a compiler flag, which lived in our .cargo/config.toml. And here's the trap: cargokit — the build helper that compiles Rust crates inside a Flutter build — was invoking cargo from the build system's working directory (Xcode's DerivedData, in the iOS/macOS case), not from the crate's directory.

Cargo discovers .cargo/config.toml by walking up from the current working directory. From DerivedData, our config file was never on that path. So the flag never applied. So every iOS and macOS release build we ever shipped ran software AES.

Why didn't the benchmarks catch it? Because when you benchmark "the Rust core," you tend to run it from the crate directory — where the config file is found. Our fast numbers and our users' slow numbers were both completely real. They were just measuring two different binaries that happened to share source code.

The fix was one line of understanding: make cargokit set workingDirectory to the crate's manifest directory before invoking cargo. (On Android the same class of problem needed a patch in cargokit's android_environment.dart to inject the aes target feature.) After the fix, on-device throughput matched the benchmarks, verified on a mid-range Galaxy A24 — the kind of phone your users actually own.

What I'd tell any team doing crypto behind FRB

Benchmark the shipped artifact, on a device, in release mode. Not the crate, not the simulator, not a debug build. Debug-mode Dart is roughly 10× slower on hot loops, so debug numbers are noise anyway — and as we learned, even a release crate benchmark can be measuring a different binary than the one in your .ipa.
Treat build-system working directories as hostile. Any configuration that's discovered by walking up from CWD — .cargo/config.toml is not the only offender — will betray you the moment a build helper invokes the toolchain from somewhere unexpected. Prefer flags that travel with the invocation (env vars, explicit --config) or pin the working directory yourself.
Make performance a test, not a vibe. After this incident we added a benchmark mode to the app itself (BISHARE_BENCH=1) so throughput on a real device is one command away. If a regression like this ships again, we want a user-visible number to disagree with us immediately.
Delete work the cipher already does. While profiling, we also found our Dart layer computing an extra SHA-256 over data that had already passed through per-chunk authenticated encryption. AES-GCM's tags already prove integrity, chunk by chunk — the checksum was proving it again, slower. We verified received bytes were identical with and without it, deleted it, and got a free speed bump. If you're layering integrity checks on top of an AEAD, ask what, exactly, the second check catches.

The part where this is a pitch (briefly)

The app this happened to is open source and on the stores: LAN transfers with mDNS discovery, a browser receive path so the other side needs no app, QR-stream transfer for the no-network case, 13 languages.

Repo: https://github.com/BIShare-project/bishare-flutter
The Rust protocol crate: https://github.com/BIShare-project/bishare-protocol
App/downloads: https://bishare.app

If you've hit your own cursed FRB or cargokit build behavior, I'd genuinely like to hear it — and if you speak a language we don't ship yet, translations are a 15-minute PR.