An opinion piece arguing that MCP servers often fail because teams build them without confirming real user demand, and recommends validating with actual struggling users and early usage instrumentation before committing.
In April a client asked us to figure out why their MCP server wasn't getting traction. It took us about 90 seconds. There were 61 tool calls in three months and 58 of them from their own engineers testing it and the launch itself had gone fine, that wasn't it. Directory listing, an announcement post, some congratulations in the comments from people who never came back. No one had asked out loud, who the user was supposed to be before the build started. I went through the Slack history to make sure and no one ever did. Quick disclosure since opinions like this need a source: it has been 8 years of me building software and MCP work is now a decent slice of what clients pay us for. So I'm criticising my own dinner. I also built a server of my own during the early excitement and it made me nothing because it solved nothing anyone was actually stuck on. That took me maybe a year to admit. The confusion I keep seeing is that a server makes your product reachable by an agent and teams treat reachable as if it meant wanted. Integration is real engineering with clear completion criteria, which is why everyone inclines to it.... you can finish it. Whether anyone was ever trying to make an agent do your task and failing, is a much less comfortable question and no amount of merged pull requests answers it. Meanwhile the directories have filled up with thousands of servers, a big share of them obviously abandoned. When we ask new clients why they want one, the honest answer under the slideware is usually some version of "our competitors have one." I lived through 2022 when every consumer brand shipped a wallet login and an NFT drop that maybe a dozen people touched and this has the same smell. The money is flowing to the gateways and registries and auth layers rather than to the servers themselves. None of this is the protocol's fault, for what it's worth. It does its one job fine. The problem is discoverability. A human has to find your server among thousands which is the distribution problem software has always had. Then the agent has to pick your tool at the moment of need and anyone who's watched a model with 40 connected tools lean on the same 3 favourites knows how that goes. Neither of those is something a protocol can fix for you. They were the job before MCP existed and they're still the job now. The test we run now, before anything gets built is that we find 5 real people already trying to make an agent do the task and failing. People who say it sounds useful don't count, you want the ones who tried and got stuck. Then instrument every call from day one and agree, in advance, on the number that triggers a shutdown. Our April client is rebuilding around one workflow two actual customers kept asking for and early usage is already an order of magnitude past the old server. Build it and they will come was a movie line and even in the movie the guy nearly lost the farm doing it.
According to @smthomas3, most companies with multiple engineering teams are building MCP servers, referencing a HN discussion on whether MCP is dead and input from OpenAI's @mxstbr.
Most MCP servers are unnecessary; this article presents a framework for deciding when an MCP server is warranted, emphasizing the need for stable APIs and CLIs first.
The article argues that MCP, originally useful for connecting LLMs to external services, has become outdated due to advancements in LLMs that can now handle API calls directly, rendering many MCP servers unnecessary.
A practitioner shares their experience with MCP (Model Context Protocol) servers for business work, detailing which ones provide real read/write capabilities (e.g., Postgres MCP, HubSpot MCP, PostFast) and which disappoint (e.g., Slack MCP, Google Ads MCP), while highlighting major security concerns like low OAuth adoption and high vulnerability rates.
A discussion about the lack of vetting for MCP servers before installation, highlighting a study that found 5.5% tool-poisoned and 14.4% with known bugs, plus a systemic RCE in the MCP SDK.