If you've been building with MCP (Model Context Protocol) servers, here's something that should make you pause before running your next install. A developer going by jiangw2718i on DEV.to published a deep-dive analysis this week that exposes some uncomfortable truths about the ecosystem's dependency footprint — and the numbers are striking.

The Setup That Started It All

The author set out to build a simple MCP server with a straightforward goal: publish something minimal. Their creation consisted of just two files totaling 145 lines of code, exposing a single read-only tool that communicates via JSON-RPC over stdio — the protocol's intended transport mechanism. When they ran npm install on their package before publishing, the results were sobering. That modest little server pulled down 95 packages onto the target machine. Ninety-five. For two files and one tool.

The Bigger Picture: Ecosystem-Wide Analysis

But the author didn't stop at their own project. They expanded the analysis to examine what was happening across a broader sample of MCP servers in the ecosystem, and the findings reinforced the pattern. The median MCP server installation brings in 94 packages — essentially identical to their two-file example. More surprisingly, 88% of these servers are pulling an HTTP framework into a process that communicates exclusively over stdio.

Why Does This Matter?

HTTP frameworks like Express, Fastify, or Hono make perfect sense when you're building web services that need to handle incoming HTTP requests. They're designed for exactly that use case — listening on ports, routing HTTP traffic, handling request/response cycles over network connections. But MCP's stdio transport is a different beast entirely: it's a local, synchronous communication channel meant for parent processes spawning and talking directly to child processes through standard input and output streams. In other words, most of the ecosystem is bringing in web server infrastructure to run inside what amounts to a command-line subprocess. The overhead isn't just theoretical — it's real packages being downloaded, installed, and loaded into memory every time an MCP client spins up a server.

What This Means for Developers

This analysis serves as a useful reminder that dependency choices have consequences beyond just package.json entries. When you're selecting libraries for an MCP server, consider whether you actually need the full feature set of an HTTP framework or whether something leaner would serve your use case better. The ecosystem has grown quickly, and with growth comes accumulated assumptions about what tools are "standard" — even when those standards may not fit the actual problem.

Key Takeaways

  • A minimal MCP server (2 files, 145 lines) still pulled down 95 packages on installation
  • The median MCP server in the ecosystem installs 94 packages total
  • 88% of analyzed servers include HTTP frameworks despite using stdio transport
  • This represents potential overengineering for local, synchronous communication patterns

The Bottom Line

The MCP ecosystem is young and still settling into its conventions. Before reaching for familiar web framework patterns, ask whether they actually fit a protocol designed for stdio communication. Sometimes the best dependency is no dependency — or at least a smaller one.