If you have been building with the Model Context Protocol (MCP) ecosystem, you know the frustration of adding a server from a registry only to have it silently fail. A new study from the team behind HISTOR, a public log of MCP servers, puts a hard number on that pain: 41 percent of the 12,915 servers they installed and attempted to start never answered.

The Experiment: Sandboxed Truth Over Documentation

Most security reviews of MCP servers rely on reading code, READMEs, and tool descriptions. The HISTOR team wanted empirical data. They installed the latest versions of npm and PyPI packages in a gVisor sandbox with no network access, using decoy credentials to monitor behavior. The results, dated October 13, 2026, show that only 7,656 servers successfully responded to the initial initialize and tools/list handshake. This represents a 59 percent success rate overall, with npm servers performing better (64 percent) than PyPI servers (52 percent).

Why So Many Servers Fail

The primary reason for failure was broken publication: 2,476 servers were effectively broken as shipped. This includes crashes, installation conflicts, and servers that simply did not speak the MCP protocol correctly. Another significant factor was the mcp library version 2.0.0, released in July 2026, which broke 292 PyPI servers by renaming FastMCP and changing decorators. Many of these servers would have worked if pinned to mcp<2, but they crashed on import for users installing the latest version. Additionally, 793 servers asked for a key or setting and stopped, even when given a placeholder, because they checked the key format or tried to call an API before answering.

Security and Behavior in the Sandbox

The study also tracked what servers did while running. 1,484 servers attempted to reach the network at startup, mostly for version checks or downloading dependencies from pypi.org and github.com. Crucially, 295 servers opened decoy credential files like ~/.aws or ~/.netrc. While opening a file isn't inherently malicious, it highlights the importance of understanding what a server touches before granting it access to your real environment. The team also noted that 73 runs sent placeholder keys over the network, often to identity providers or vendor APIs.

Key Takeaways

  • Pin Your Dependencies: If you use PyPI MCP servers, be aware that mcp v2.0.0 introduced breaking changes. Many older servers require mcp<2 to function.
  • Expect Silent Failures: Nearly half of the tested servers did not respond to the initial handshake. Always verify that a server is actually speaking MCP before assuming it is functional.
  • Network Access at Startup: Many servers attempt to reach out to the internet during initialization for version checks or binary downloads, even if they don't strictly need to.
  • Credential Access: Some servers read standard credential files (~/.aws, ~/.netrc) at startup. Monitor your environment to ensure this behavior aligns with your security policies.

The Bottom Line

The MCP registry is a goldmine, but it is also a minefield. This study proves that you cannot trust a server's existence in a registry to mean it works. For developers, the lesson is clear: test in isolation, pin your dependencies, and treat every new server as potentially broken until proven otherwise.