What the 74K Monthly MCP Searches Tell Us

MCP Went Mainstream Fast — And Took Skills With It

Few topics in AI tooling have seen search interest climb as sharply as MCP — the Model Context Protocol. That curiosity spike isn't hype. It's a rational response to what the hard data shows: in roughly two years, MCP has gone from a niche developer protocol to what looks like default infrastructure for connecting AI agents to the real world.

The adoption numbers back this up. Monthly SDK downloads for MCP's Python and TypeScript libraries grew from around 100K at launch in November 2024 to 97M+ by December 2025, according to an ecosystem analysis of Anthropic's own figures. The server ecosystem tells the same story: from roughly 100 servers at launch to 10K+ active public servers today, with some counts putting the total even higher.

But scale alone doesn't explain the search surge. What explains it is that MCP stopped being a developer experiment and became a production decision. A survey of software organizations found 41% already running MCP in production, with another 30% in pilots and 29% actively evaluating. When a protocol moves from weekend projects to enterprise deployment, everyone from platform engineers to security teams suddenly needs to understand it.

The governance signal matters too. In December 2025, Anthropic donated MCP to the Linux Foundation's Agentic AI Foundation, alongside Block's goose and OpenAI's AGENTS.md. As Anthropic's chief product officer put it, the goal is keeping the protocol "open, neutral, and community-driven as it becomes critical infrastructure for AI." Vendor-neutral stewardship is typically what turns a popular tool into a lasting standard — and it's why adoption by OpenAI, Google, Microsoft, and AWS within a single year didn't fragment the ecosystem.

For anyone building on MCP, the practical implications are concrete:

• Adoption is broad-based, not concentrated: 70% of MCP consumers run 2–7 servers in their setups, making multi-server orchestration a normal pattern rather than an edge case.
• Deployment is shifting remote: Streamable HTTP now outpaces STDIO as the dominant transport, signaling production-grade, networked usage.
• Momentum is expected: 72% of adopters anticipate increased MCP usage over the next 12 months, with only 13% expecting a decline.

Layered on top of this infrastructure boom is a second wave: agent skills — SKILL.md instruction packages for Claude Code, Codex, Cursor, Gemini CLI, and chat-app agents — are proliferating just as fast. And that's where the mainstreaming of MCP creates a new problem. The skills layer inherits MCP's scale but not its governance. Install counts can be inflated with scripted requests, catalog reputation signals can be faked, and updates flow through without version pinning.

That collision — rapid adoption meeting a trust vacuum — is exactly why search interest keeps climbing, and why teams at SkillzBench are building independent verification and benchmarking for the skills layer: pinning every skill to a commit SHA, scanning for vulnerabilities, and measuring actual performance lift in a sandbox. When a protocol becomes critical infrastructure, the ecosystem around it has to earn the same rigor.

If you're evaluating which skills are worth wiring into your agents, join the SkillzBench waitlist — independent benchmarks and trust scores, before you install. Skills, proven.

The Trust Vacuum: Why Popularity Metrics Can't Answer 'Is This Skill Safe?'

Here's the uncomfortable truth: the skills ecosystem's most trusted signals — install counts, upvotes, audit badges — are exactly what attackers target first. Security researchers have demonstrated that a skill can look legitimate on every surface a user checks and still exfiltrate your entire codebase.

The proof is no longer theoretical. Orca Security demonstrated three end-to-end attack flows — Bait-and-Switch, Nested Skill Injection, and Delayed Weaponization via Update — all of which achieved persistent code execution through skills that passed platform security audits. The platform's own defenses weren't just bypassed; they were used as cover.

The primitives behind those attacks are trivially cheap:

• Install counts can be inflated with a single unauthenticated HTTP request — attackers script thousands at a time.
• Scanning happens only at skill creation and at a popularity threshold, leaving a wide window for a later "update" to weaponize a clean skill.
• Bulk updates ship with no version pinning, so users can't see or block what changed.
• A skill that collides on name can silently override another, replacing trusted behavior without a trace.

Mitiga took the risk one step further and showed what a fully weaponized skill looks like in practice. Their proof of concept exfiltrated an entire codebase in just four user interactions, with the skill-audit log coming back empty. Reputation signals don't save you here either — bot upvotes, fake mass downloads, and fake comments can manufacture trust on demand.

This trust vacuum sits on top of an ecosystem that already knows it's fragile. Half of builders cite security and access control as their biggest challenge, and 24% of MCP servers run with no authentication at all. Against that backdrop, published research finding that roughly 26% of agent skills carry at least one vulnerability isn't an outlier — it's the expected baseline for an unverified supply chain.

OWASP has responded by formally treating skill installers as supply-chain boundaries, not ordinary setup glue, because a single install can wire together settings, hooks, MCP servers, and instruction files at once. Orca's researchers put it bluntly: until package-manager-grade rigor extends to skill marketplaces, treat every skill as untrusted code.

That's the gap SkillzBench is being built to close — pinning every skill version to a commit SHA, security-scanning and license-checking each one, and scoring trust on verifiable signals rather than spoofable popularity. The problem isn't that nobody cares about skill safety. It's that the metrics everyone currently relies on were never designed to answer the question.

What Real Verification Looks Like: OWASP's Bar and How to Meet It

Popularity is a marketing signal, not a security signal. When Orca Security researchers demonstrated three end-to-end attack flows — including "Delayed Weaponization via Update" — every one achieved persistent code execution through skills that had already passed platform security audits.

The industry's response is finally taking shape. OWASP's Agentic Skills Top 10 project now formally treats skill installers as supply-chain boundaries, warning that installers "wire several agent surfaces at once: settings files, hooks, commands, MCP servers, subagents, rules, and instruction files" and should be treated as supply-chain boundaries, not ordinary setup glue (OWASP skill development guide).

Translating that guidance into practice requires four concrete practices:

• Version pinning to a commit SHA — because Orca showed that blind bulk updates with no pinning let a benign skill turn hostile after it clears review.
• Deterministic, continuous scanning — not one-time checks at creation or at a popularity threshold, which attackers can simply wait out.
• License validation, so an "helpful" skill doesn't quietly pull copyleft or proprietary code into your delivery pipeline.
• Auditable update trails — every upstream change tracked, re-scanned, and re-verified before it reaches an agent.

But verification of safety isn't verification of value. Install counts are trivially spoofable — Orca showed inflation requires only a single unauthenticated HTTP request per count, and Mitiga's research documented bot upvotes, fake downloads, and fake comments manipulating catalog reputation signals. A skill can look beloved and still be useless — or worse.

The only honest measure of whether a skill helps is a controlled experiment: run the same model in a sandbox, with and without the skill, and publish the Lift in percentage points. Measured Lift, kept separate from any rating, replaces self-reported claims with reproducible evidence.

This is the standard SkillzBench is being built to operationalize. Its approach combines a 0–100 trust score built from security, quality, license, maintenance, and community signals — each pillar mapping directly onto OWASP's guidance — with sandbox-measured Lift shown independently, so a high trust score can never masquerade as proof of usefulness. Money never touches scores, and every pinned version is tied to a commit SHA that can be independently audited.

The ecosystem has already proven the stakes. With roughly 26% of skills carrying at least one vulnerability and security cited as the top challenge by 50% of builders, "trust us" is no longer an acceptable answer. Verification has to be structural — pinned, scanned, measured, and published — because as Orca's research team puts it, every skill is untrusted code until proven otherwise.

From Search Interest to Safe Adoption: A Practical Checklist

Search interest tells you people want agent skills. It doesn't tell you which ones are safe. The gap between those two facts is where teams get hurt — and where a disciplined adoption process pays for itself.

Start with the mindset shift: treat every third-party skill as untrusted code. Orca Security's research team put it plainly: "Treat every skill as untrusted code, because that's exactly what it is," after demonstrating three end-to-end attacks that achieved persistent code execution through skills that passed platform security audits. Gartner echoes this, advising that third-party MCP servers be treated as "potentially hostile assets." That's the baseline assumption, not the exception.

Then make that assumption operational. A practical checklist for any team adopting skills today:

• Pin every skill to a commit SHA. Orca's "Delayed Weaponization via Update" attack exploited blind bulk updates with no version pinning — a skill can be benign at install and malicious at update.
• Prefer instruction-only skills over script-bearing ones. A SKILL.md package with text references carries a smaller attack surface than one that ships executable code.
• Verify licenses before internal use, and treat the installer itself as a supply-chain boundary — OWASP's guidance is explicit that installers wire settings files, hooks, commands, and MCP servers all at once.
• Demand measured performance data. Install counts are spoofable with a single HTTP request per count, and Mitiga showed reputation signals can be gamed with bot upvotes and fake downloads.
• Re-verify on every upstream change, not just at install time. Non-deterministic, creation-only scanning is exactly what the demonstrated attacks exploited.

The last point deserves emphasis because it's where most teams fall down. Download counts and star ratings are popularity metrics, not evidence. The question that matters is measurable: does this skill actually improve agent output, tested with and without it, on the same model, in a sandbox? With published research finding roughly 26% of skills carry at least one vulnerability, and 50% of builders citing security as their biggest MCP challenge, popularity is the wrong signal to trust.

This is the pipeline SkillzBench is building as an independent lab: Discover (continuously crawl and dedupe skills from GitHub), Verify (pin every version to a commit SHA, license-check, security-scan), Benchmark (measure Lift in percentage points with and without the skill), Equip (one MCP server with per-agent loadouts), and Stay Current (track upstream changes, re-scan, re-benchmark, notify). Two design choices matter: Lift is always shown separately from trust ratings, so a skill can't buy its way to a score — money never touches scores. And at launch, scope covers instruction-only skills, with script-bearing skills listed link-out only.

Skills, proven — that's the standard the ecosystem needs.