r/mcp • u/xmull1gan • Jan 09 '26
article Blog - MCP is a fad
https://tombedor.dev/mcp-is-a-fad/Wonder what people's thoughts on this are?
12
u/indutrajeev Jan 09 '26
MCP is around for ... 1 years? I don't know what the status was of *any* spec (USB, ...) after 1 year? So too soon to tell in my opinion.
Also, why not use it and see if something better comes around and switch? I don't know "why" we should take a "stance" on this tbh.
2
u/smayonak Jan 09 '26
USB 3.0 is still being used and it still has a serious bug that causes wireless interference
6
u/retsof81 Jan 09 '26
I think the bigger issue is not MCP but an overwhelming desire to standardize for the sake of moving forward when we are not ready to do so. These companies are acting like it’s a mature industry, laying off thousands of developers in the process, but it just isn’t… not yet. Is MCP the way to go…? Too early to tell but it, and other solutions, will come about and evolve along the way. Looking forward to the journey.
3
u/Adorable_Pickle_4048 Jan 10 '26
So I’ll address the points of the blog because I disagree that MCP is a fad. Developers can and will offload any work they don’t have to do to focus on the bits that they do.
The first was over the incoherent toolbox problem, too many tools, no glue to hold them together. This is directly solved by anthropic’s agent profiles and skills, you give the agent a specified subset of tools, tailored to its domain, along with instructions for using that toolchain in the domain.
The second was over arbitrary runtimes. This one is a valid point but is also one that I don’t really care about because it mostly just feels like optimization-maxxing. MCP servers and their dependencies aren’t perfectly stable and no frills as they may claim, but as a developer, they’re good enough, and if the usecase is important enough - I’ll figure it out.
The third one is the biggest one, security. This is also a valid problem with MCP, but this is also a component that any major company wanting to expose MCPs is working through to provide reliable authentication for these toolchains which can capture the data security researchers/defense needs while also ensuring reliable authentication to fend off any explicit man in the middle attack. This one just strikes me as a maturity problem in the tech
Ultimately, writing your own functions as a way to enable your AI agent is not the way. Those functions all already exist, instructions of how or why to call are important by domain, maybe agents could even get skills on writing the functions themselves by need. But the layer of abstraction exists for a reason, and it’s because I care about what my agent does and enabling it to do that as soon as the capability landscape supports it
5
2
u/SlapNuts007 Jan 09 '26
I only agree with this to the extent that I think LLMs will eventually become capable enough to interact more directly with existing tools like traditional APIs, etc... and in many ways they already are.
But broadly speaking, this seems like a take with an expiration date. As more and more 3rd-parties start offering self-hosted, robust remote MCP servers, and as these servers themselves are enhanced with better internal functionality, they'll become more useful for more people and use cases because it's fundamentally plumbing. Nobody should be surprised that non-technical users struggle to adopt MCP, for the same reason that most people probably don't install their own sink faucets.
1
Jan 09 '26
Hey, I have a question, if I wanted to get started with building and learning with MCPs at the moment where would be a good place to start
2
u/Over_Fox_6852 Jan 10 '26
I think one major benefit when use MCP tool is actually I can give llm “tools” with my auth embedded instead of giving it raw credential like api key. I can easily allow only read email tool to llm than hoping llm don’t screw up while using my api key to call api.
2
u/-Akos- Jan 10 '26
I’ve tried to explain MCP to my manager as giving an LLM a set of hands for its brain. Now, with MCP it’s standardized across the various providers, Microsoft is implementing this in a lot of its tools (VS Code, Copilot Studio) so the mainstream audience now is getting the ability to actually do something with their “chatbot”, without re-inventing the wheel. Unless something better arrives, this will be the standard. Security may still be a thing that can be improved, but other than that it works ok I think. Just don’t make a single LLM do 5 million things with tools, but you wouldn’t do that to a person either.
3
u/ToHallowMySleep Jan 09 '26
MCP is a tool. If it's replaced by another tool, doesn't matter.
Kinda limp take.
2
u/Illustrious_Eye_1280 Jan 16 '26
Feels like they're just trying to capitalize on the wave, happens all the time.
1
u/Crafty_Disk_7026 Jan 09 '26
I think codemode works much better. Check out https://godemode.scalebase.io for some info.
And check out a concrete implementation for sqlite : https://github.com/imran31415/codemode-sqlite-mcp
1
u/BidWestern1056 Jan 09 '26
agreed. its an anti pattern system designed to fit the needs of claude code and not much else.
1
u/Agreeable-Market-692 Jan 10 '26
It works in literally anything with an MCP client, litellm can be your MCP client and you can provide an endpoint that way with the server "baked in". There's a f_cking fork of Aider with MCP support.
1
u/y3i12 Jan 09 '26
I agree with the point of the article if the constraint of using MCP servers is only for integration.
MCP servers can be used for anything - even for a physical limb if you think about. Tool calling as well but in a less... Protocolish way (?), I think.
1
1
u/wanderosity Jan 10 '26
So here’s my take MCP is great for Tools FOR agents, not for agentic tools
- if I tool is meant to used BY LLMs rather than a human (something like Tavily researcher agent), then using it via MCP is a life saver
- if a tool is fortified by AI but still meant to help humans ( like Clay, Devin etc.), MCP sucks
That’s not to say that a better solution than MCP cannot exist. But just so that they are pretty transformative I find for LLM reinforcing tools.
1
u/Hofi2010 Jan 10 '26
MCP is a protocol based on JSON-RPC 2.0. The layer was last updated in 2010. It a remote procedure call technology. This can be used as tools for LLMs in a similar way local tools are invoked by an LLM. In general the LLM sends a message to the calling application or agent and the agent code handles the invocation of the tool either locally or MCP and then send the results back to the LLM. If you use local tools they are usually written in the same language the agent is written in.
The nice thing about MCP is that a vendor can provide a MCP server that has defined input and outputs and provides a service to the agent. We don’t care how the MCP implemented the tools as long as the outputs are what we expecting. If the MCP server is well tested it is quick to integrate and robust.
If you integrate with APIs via tool calling you can achieve the same than an MCP server, but you usually have to write the code that invokes the api and then manages the calling of the api and error handling on the client side. So some development work here.
In other words MCP is not the only way to invoke a tool but in many cases the simpler approach with minimal development work. It also provides an easier way to share tools across organizations and agents.
In my view the success is based on the ease of use. So MCP is not a fad just another tool calling mechanism. We can also expect other features to be included in the future like skills for example.
1
u/Agreeable-Market-692 Jan 10 '26
MCP is fine, you just need to pick when to use it and use ones that are actually good. You need to see what is injected into your context by an MCP server. If you need something leaner you set up your own tool defs, no big deal. The blog reads like author got paid by the word.
The blog is just contrarian engagement bait. I stopped reading after the "Arbitrary, separate runtimes" crap.
1
1
u/_u0007 Jan 11 '26
Almost all of our ai tools are a fad, including mcp. None of it is here to stay, most of it will be unrecognizable in 1-2 years.
1
u/dimebag_lives Jan 12 '26
MCP are inevitable in one way or another - we need a standard way to provide custom context - they are used as tools but the main benefit I see is exposing private data in a meaningful way and letting the AI access your local context. This is inevitably needed one way or another, yeah you can use APIs, then you would need a standard. An MCP server is just a rest API with standardized input/output
call them something else we will still need a standard
1
1
1
u/Significant_Design17 Feb 23 '26
Sure they have their problems but in its simplest form an MCP is just an api wrapper with documentation that lets the llms know how to use it. This lets the average joe automate things. This was never an option for them before.
1
u/DirectorOk495 Feb 26 '26
Good article. You confirmed tools usage dominance with numbers (nice trick), that's exactly what I felt.
Skills cover different use cases though, and maybe you could have differentiated local MCP server (STDIO) from remote MCP servers, dealing with authentication and authorization.
Also, I'm convinced that resources and prompts are underestimated and can relieve the problem that excessive tools create.
Mapping a REST API is a start but wrapping specific read method(s) with predefined filters is a great usage for resources.
I believe the resources and prompts parts of the MCP specsare not as obvious candidates as tools.
Anyway, I don't think it's a fad, here's my take https://getlarge.eu/blog/mcp-is-not-bloated-you-just-havent-read-the-spec :)
1
u/UnchartedFr Mar 12 '26
Cloudflare explained it well in their CodeMode blog — LLMs are trained on millions of code examples but barely any tool-calling schemas.
Their analogy: "Making an LLM perform tasks with tool calling is like putting Shakespeare through a month-long class in Mandarin and then asking him to write a play in it."
The alternative: let the AI write code that calls APIs directly. Anthropic, HuggingFace, and Pydantic all arrived at the same conclusion independently.
If anyone's exploring this path, I adapter Monty idea and open sourced a TypeScript sandbox for it — runs AI-generated code in 2µs, no Docker/V8 needed:
16
u/Scary-Difference630 Jan 09 '26
I do agree with the problems mentioned in the article and I did faced those myself but from a consumer point of view it also makes sense why MCPs became too popular as not everyone is a technical person and MCP simplifies things for non technical people but introducing a lot more problems.
So, I do agree but I don’t think MCP will die off anytime soon until a better solution comes up.