I built 21 MCP servers. I use two of them
Building a tool is how I find out whether the problem is real. Keeping it is a separate decision. What 21 MCP servers taught me about which tools coding agents actually need.
, filed under ai, mcp, coding-agents, tooling, open-source
I’ve built 21 MCP servers since January 2025. I use two of them. 😅
In my defence, it seemed like a good idea at the time. Every time.
Where they went
Seven of them were single-provider search servers. Tavily, Kagi, Perplexity, DuckDuckGo, and three for Jina, each with its own server. In March 2025 I collapsed them into one, mcp-omnisearch, mostly so I’d stop maintaining several versions of the same thing. Those seven are archived.
Most of the rest quietly stopped being needed. The models got better at the job, and the tool turned into extra context and another thing to update. An agent will happily use a command-line tool and be quite good with it, so a lot of what I once wrapped in MCP doesn’t need wrapping any more.
The two I still run
The two I still run do something a model can’t do on its own:
- mcp-omnisearch searches across providers.
- mcp-sqlite-tools reads and writes SQLite safely, with read-only queries kept separate from writes.
They’re my daily bread and butter when using coding agents.
Keeping a tool is a separate decision
Funny timing, really. Corporate LinkedIn is just discovering MCP, and I’m busy archiving mine.
Building a tool is how I find out whether the problem is real. Keeping it is a separate decision. The test I use now: does it give the agent a capability it can’t get from a command-line tool and a good instruction? If not, it’s context the agent has to carry for nothing.
What a team gets from this
If you’re deciding which MCP servers to roll out across a team, start from the capability gap, not the catalogue. Fewer, sharper tools beat a long list the agent has to read every session.
Working out which tools your team’s agents actually need? Let’s talk.