I shipped ten Model Context Protocol servers under one npm scope this year. Three I use multiple times a week. Seven sit in my config file as dead weight. This is the honest ranking. The pattern is uncomfortable for the MCP-everywhere hype cycle, so I want to write it down.
The three I actually use
streamparse-mcp parses partial / truncated JSON. The trigger is the same every time: Claude is streaming output that should be JSON, the stream cuts off, I need to recover what was emitted. Asking the MCP is faster than remembering the JSON.parse recovery dance.
mcpcheck lints MCP config files. Errors in MCP configs are silent. Nothing crashes. The tool just is not there. A two-second lint catches the typo before ten minutes of "why does Claude not see my server."
agentvet-mcp validates tool-call args before execution. Lets Claude pilot a tool I have not fully trust-listed. The LLM-friendly hints make Claude self-correct better than a stack trace would.
The seven I built and rarely touch
agentcast-mcp, agentguard-mcp, agentfit-mcp, agentsnap-mcp, promptbudget-mcp, citecite-mcp, ragmetric-mcp. Each one was a good idea when I shipped it. Each one is useful in scripted workflows. None of them earn their place in interactive chat.
The pattern
Two things separate the top three from the bottom seven.
Top servers fix things that happen often and silently. Bad MCP configs do not throw exceptions. Truncated streams do not crash. Hallucinated tool args run silently with the wrong inputs. Catching them at the moment they happen converts silent failure into a clear error message. That is high-leverage.
Bottom servers reproduce things Claude can already do. Arithmetic on small inputs, paraphrasing, summarizing one paragraph. Claude is fine at these. An MCP server that wraps "do this thing Claude can already do" is mostly redundant in chat. It earns its keep only in scripts where you need determinism.
The middle is "useful in scripts, quiet in interactive use." That is real, but they shine in CI, not in your daily chat.
What I would build differently
I would build fewer MCP servers and more CLI tools.
Half my MCP servers should have been CLIs that I pipe into Claude. The MCP server is the right shape when Claude needs to decide whether to call the tool mid-conversation. The CLI is the right shape when I decide and want to paste the output.
If you are choosing between a CLI and an MCP server for a new idea, default to the CLI. Convert to an MCP server later if you find yourself wanting Claude to call it mid-conversation. Going the other direction is the path I keep regretting.
The uncomfortable bit
The MCP ecosystem will tell you to build a server for every problem. I built ten and use three.
If yours look like the bottom seven, that is not your fault. The tools are not bad. They are wrong-shaped for interactive chat. Move them to CLIs and you will use them more.
If you build something that fixes a thing that happens often and silently, you will end up in the top tier. That is the test.
All ten are in the official MCP Registry under my npm scope. The top three are worth the install. The rest are situational; install them when you hit the problem they solve, not before.
Top comments (0)