The part that stuck with me is not the article’s main thesis so much as the quiet admission hidden inside it: if you strip away the MCP enthusiasm, a lot of agent plumbing starts looking suspiciously like plain old HTTP APIs and CLI tools with a nicer story wrapped around them. That does not make MCP useless. But it does make me question how much of the ecosystem’s current excitement is about a real protocol need versus the convenience of having a shared banner to rally around.
I’ve always thought MCP was appealing for a very specific reason: it promises to standardize the awkward middle layer between models and tools. In practice, though, the article makes a decent case that this middle layer may be less universal than people hoped. For internal systems, a normal API plus a bit of schema discipline may already be enough. For agent workflows, especially where the model is driving tool use, the useful abstraction might simply be “good tool design” rather than a dedicated protocol stack.
What I find most convincing here is the criticism around discovery and context handling. The article argues that MCP server adoption tends to create another layer to manage, another thing to catalog, another place for accidental complexity to accumulate. That rings true. The moment a protocol becomes a place where people publish “tools for tools,” you can end up with a meta-ecosystem that is more impressive on slide decks than in day-to-day engineering.
The bit about standard HTTP headers, especially Accept: text/Markdown and Accept-Language, is actually the sharpest part of the argument. It’s not saying “protocols are bad.” It’s saying that the web already solved a lot of content negotiation, and some of what people want from MCP may just be a thinner, more conventional way of serving structured responses to agents. I think that’s a fair challenge. If an agent can get what it needs from a well-formed API, plus maybe a CLI wrapper for the odd task, the added ceremony of a separate protocol has to earn its keep.
That said, I’m not fully ready to bury MCP. Standardization often looks silly right before it becomes normal. The article’s line of attack is strongest against the hype, not necessarily against the core idea. If MCP ends up being useful, it will probably be because teams want a shared contract for tool exposure and not because they enjoy inventing another transport layer. But if I were building today, I’d be cautious. I’d start with boring primitives first and only reach for MCP when I could point to a concrete problem it solved better than HTTP, CLI, or an SDK.
Reference: [��������MCP�T��o�͕s�v�Ȃ̂��H�@����ɂȂ�Z�p���J���҂��FLLM�i���ŗh�炮���݉��l
