MCP at 97 million — Brandon Miller
·4 min read· ai· mcp· tooling· mobile

MCP at 97 million

Model Context Protocol hit 97M monthly SDK downloads in March and now sits under the Linux Foundation. What that means for what a mobile engineer should build.

MCP at 97 million

Anthropic reported 97 million monthly SDK downloads for the Model Context Protocol in March, with more than 10,000 active public servers. Put next to the timeline, the scale is hard to ignore: MCP hit that mark in 16 months. React took roughly three years to get there.

The governance story matters too. Anthropic donated MCP to the newly formed Agentic AI Foundation under the Linux Foundation in December 2025. OpenAI and Block joined as co-founders. AWS, Google, Microsoft, Cloudflare, and Bloomberg signed on as supporting members. By March, every major AI provider supported the protocol in their flagship products. It's past "de facto standard." It's the standard.

For someone building mobile coding agents, this is the piece of the year that changes what's worth building and what isn't.

What's worth building: MCP servers that expose platform tools the agent needs. The Xcode 26.3 MCP surface is the template — a build system, a test runner, a preview capture, a documentation search, all behind one protocol. On the Android side, nobody has shipped the equivalent for Gradle, the Android emulator, adb, dumpsys, Compose's layout inspector, or Espresso. Those are the obvious next entries. Write them as MCP servers and every compliant agent gets them for free.

What's worth building: device-level MCP servers. A adb-backed server that exposes the running app state — activity stack, fragment tree, logcat streams, view hierarchy dumps — as MCP tools. An iOS equivalent over the simulator or a physical device. The reason runtime observation is hard for agents isn't that the primitives don't exist. It's that nobody's wrapped them in a surface the agent can drive. MCP is that surface now.

What's not worth building: platform-specific agent protocols. The year where every vendor shipped a proprietary "how our tools talk to your IDE" is over. If you build a new agent surface and it doesn't speak MCP, you're building for one product's install base. If it does, you're building for all of them.

What's not worth building: custom glue code that stitches together vendor-specific tool-use schemas. The thing MCP replaced was the N-times-M problem — N agents, M tools, and a custom integration at every intersection. If you still have integration code that looks like that, it's dead weight. Rewrite it behind MCP and forget about which agent consumes it.

A concrete example from my own setup. Six months ago my Claude Code configuration for Android work had custom tool definitions for ./gradlew, the Android emulator, and adb logcat. They were Claude-specific. Last month I rewrote them as an MCP server. Today the same server serves Claude Code, Xcode's agent, and a Cursor session I run occasionally for comparison. Zero per-agent configuration. The protocol carried the weight.

The thing about standards is they feel like overhead until they're not. At 97 million downloads, MCP is not overhead anymore. It's the infrastructure. The mobile tooling work worth doing in 2026 is the work that sits on top of it.