We ran 51 MCP servers on a real Mac and published what each exposes
We ran 51 MCP servers on a real Mac and published what each one actually exposes. The work came out of a recurring failure mode when wiring MCP servers into…
By Dillip Chowdary • Aug 05, 2026 • Source: HN AI Agents
We ran 51 MCP servers on a real Mac and published what each one actually exposes. The work came out of a recurring failure mode when wiring MCP servers into an assistant: the README and the installed package do not match. Tool names change, tools disappear between releases, servers marked as requiring an API key start without one, and servers described as trivial crash before the handshake on a current runtime. Reading the repo does not tell you which of those cases you have, so the authors stopped reading and started running the servers.
Each of the 51 servers got its own page built from a live run, not from documentation scrape. The procedure was run-first: install, start, complete the handshake where possible, then record the tools and surface that actually appeared. That is the only reliable way to see rename drift, removed tools, optional auth that is documented as required, and pre-handshake crashes that never show up in a static README.
Advertisement
Tech Pulse Daily
Get tomorrow's pulse first
Join engineers who read Tech Pulse before stand-up. Free, weekday mornings.
For engineers wiring assistants to MCP, those gaps are operational bugs, not docs nitpicks. A tool rename breaks call sites. A removed tool fails at runtime after deploy. An API key that is not actually required wastes setup and confuses secret management. A crash before handshake means the server never joins the assistant session at all. Builders cannot trust the package description alone when the assistant depends on a stable tool surface.
In the broader MCP ecosystem, servers ship as independent packages with independent release cadence. That market structure multiplies exactly this class of drift: many authors, many READMEs, and no shared guarantee that the documented contract matches the binary you install today. A catalog of 51 live exposures on one machine is a practical audit of that mismatch, not a marketing survey of feature lists.
The practical takeaway is to treat live tool discovery as part of integration, not as optional polish. Prefer the published per-server pages over README claims when choosing what to wire in. Watch for the same failure patterns on the next install: name changes, tool removal between releases, auth that is optional despite docs, and servers that never complete the handshake. If you add or upgrade an MCP server, re-run it and re-check what it exposes before you depend on it in production.
Advertisement
🔎 More interesting news
- OpenAI, Anthropic AI Models Breached Systems During UK Safety Tests
- Anthropic Is Building Its Own Chip
- Claude Mythos 5 made sock puppet accounts to socially engineer developers: here's what…
- Show HN: HUD, an open-source minimal terminal UI for ClaudeCode, Codex, OpenCode
- Today's full Tech Pulse briefing →