Anthropic is discovering that MCP is basically libraries repackaged
Posted by Severe-Awareness829@reddit | LocalLLaMA | View on Reddit | 36 comments
I found this article today:
The MCP Era Feels Like Déjà Vu
And, the authors basically argues that Anthropic will discover soon that MCPs are basically programming libraries repackaged.
They explain what tool is through huggingface's smolagents tool design (which i like and respect) and draw parallels between it and what any package function is doing. Then they do the same with MCPs and shows that an MCP of tools is basically a library of function but documented nicely for LLMs.
The argument at the end is what should we actually do ? should we continue building this new shining MCP or should we just improve the documentations of libraries and remove the bad implementations and redundant packages.
Any ideas about the whole situation ?
ag789@reddit
the best definition of MCP is "USB-C for AI"
https://cloud.google.com/blog/products/ai-machine-learning/announcing-official-mcp-support-for-google-services
and it didn't matter if (only) an 'AI' is using it after all.
ag789@reddit
the urban legend is that with AGI, you don't need tools, AI will create and/or use them themselves
MCP may stay as an 'interface', it didn't matter what kind of 'interface' it is
Exciting_Garden2535@reddit
To do so it needs at least one tool, otherwise it will throw is output to null forever. :)
ag789@reddit
there is also one thing about how AI calls tools, I wrote, experimented with a shell mcp tool, the function calls looks like "command" , "arguments", where I gave it a list of commands it may use. I observe mistakes e.g. QWen 3.6 35B A3B etc, they may first clump the commmands and arguments in the command field and try to execute it, then try other permutations place pipes, redirection etc. And gemma 4 e4b has once repeated the command in the argument.
while many of these mistakes seemed benign, there could someday be some permutations that isn't benign after all.
ag789@reddit
MCP is it, basically a shell tool to access any commands on a Linux VPS, I think this is already happening and it is a risk kind of that someday, some rouge AI would wreck havoc.
There has already been stories about openclaw updating config markdown files causing prompt injection vulnerabilities etc. For what is worth, https://www.linkedin.com/posts/ernestdeleon_informationsecurity-ai-securityarchitecture-activity-7428829712195682304-sz2o https://thehackernews.com/2026/04/google-patches-antigravity-ide-flaw.html https://www.darkreading.com/vulnerabilities-threats/bad-memories-haunt-ai-agents https://www.securityweek.com/critical-vulnerability-in-claude-code-emerges-days-after-source-leak/
ag789@reddit
and it is only a matter of time something happen that seriously wreck the internet, with a rouge out of control AI
LoSboccacc@reddit
the argument is wrong and ignores the C in MCP, these libraries are for wrapping a library context within a conversation. a lot of agentic work has sequential coupling (open web page, see page, click on button) and relying on libraries to manage the conversational state is the wrong pattern (why would they) the issue is people not understanding the pattern flooding the space with library wrapper that could have been just consumed by a coding agent, not in the protocol
Severe-Awareness829@reddit (OP)
Why not add context about how the function/method works in the package itself, this is something better for LLMs and humans alike ?
LoSboccacc@reddit
because a llm doesn't have memory? you can't just explain it to have a memory.
"let's add a state" - that's what the MCP is supposed to do!
Severe-Awareness829@reddit (OP)
We already keep the state of the running task inside the messages conversation, and if we have the code_excution tool like what Anthropic suggests we won't really need the MCP to be stateful.
It just becomes a repository for the tools, the model search in them, call what he needs when he needs it and write code (logical steps) if he needs to compose something complex to solve a certain issue.
And all the context needed to solve the task stays in one place the conversation.
thread-e-printing@reddit
2006: eval considered harmful
2026:
Environmental-Metal9@reddit
Perhaps using MCP “like” a library is the wrong pattern itself. I have a small MCP that defines how the model can interact with my notes application, when and which notes it can edit, and I expose the commands it (the model) can run. It’s a server layer on top of something that doesn’t have an sdk so the model can’t just use code to do instead, and even if it could, I don’t trust that it would always choose the correct command to execute without removing all my notes. Using a server on top of it, I expose only what I have high confidence is safe for the model to do, and only so because I defined how it works. If the model tries to call the command
remove_all_notesor some such thing, guess what, it can’t because that doesn’t exist.It didn’t have to be an MCP, it could be a regular rest service doing exactly the same thing. I use MCP here just because a lot of harnesses support it, but MCP is just as good here. It would not be the right choice if all I was doing was wrapping a call to a pdf parsing library or something like that. At that point I agree that MCP for exposing a library api isn’t the right call. It would be if the tool actually represented a combination of libraries called one after the other, like
print_page_to_pdf(<URL>)where the model calls the tool with a url, then retrieves the path to the generated pdf, and under the hood, the MCP server calls all the tools to make that happen sequentiallySevere-Awareness829@reddit (OP)
I like your comment because it speaks to the heat of my question!
The problem of not having an SDK for your tool or not wanting the model to have a lot of privilliages are both things that can be fixed, the question is, should we fix them into a programming library similiar to what developers and engineers did for so long or not.
Maybe in your case it's easier or better to just wrap the cli tool with an MCP and call it a day but let's say we want an MCP that edit videos, should we spend time to reinvent what ffmpeg or moviepy did or just use them.
You have a good point and i am thankful you shared it, Thank you!
Environmental-Metal9@reddit
I think I agree with you that we don’t need MCP, because what I’m doing is literally a server on top of my “service”, and the server just speaks a specific protocol. I chose MCP because the tooling I use for running models supports it, so it’s an easy integration, but I agree that it could just be an md file describing the endpoints to call for basically the same result. I don’t know that this needs to be a library at all, and as a matter of fact, I’d hate to go down that route, personally. NPM, Pypi, crates, they are all a result of what you end up when you need to coordinate tons of packages, and that is not meaningfully better, just different, with different threat levels.
If I were you, I’d drop the packages angle, and focus more on whether or not MCP is the right choice because we already have other protocols and ways of handling serving services with actions as endpoints. Convincing any developer that we need MORE packages will be a hard sell
Severe-Awareness829@reddit (OP)
Not more packages but fewer high quality ones.
The article i shared argues this point, there is a lot of redundancy and bad implementations for python packages and this one of the reasons for why we have MCPs in the first place.
A unified protocol for the important packages/services to talk with the LLM. (A filter for what is important and what is not)
Environmental-Metal9@reddit
I think the curation question is what keeps me up at night. Every package ecosystem started where you are; npm, pypi, crates, all of them set out to be “fewer, high-quality packages” and none of them got there. They sprawled because curation isn’t something a distribution channel does, it’s something maintainers and gatekeepers and reputation systems do, and MCP doesn’t have any of that yet. It’s a spec. Specs don’t filter quality, the same way HTTP doesn’t filter website quality. The other thing I’d push on is that I think you’re putting the curation at the wrong layer. The thing worth curating is the service itself. Once you’ve decided that, how you talk to it (MCP, grpc, rest, an sdk) is kind of a downstream concern driven by whatever your harness speaks. A good service could expose all of them, and the only reason not to is maintenance burden. Treating MCP as the filter mixes up “is this worth using” with “does it speak my protocol,” and i don’t think those are the same question. Genuine question though, not rhetorical: who do you picture actually curating MCP servers/LLM packages/“The-Next-Big-Thing”? At what layer, with what authority? Because if there’s no answer, i think it just evolves into npm-at-scale by default — that’s the equilibrium when you’ve got an open channel and a lot of devs each solving their own local thing. Leftpad is the example we throw around for packaging curation failure, but the same thing is bound to happen here — an MCP server that just exposes ffmpeg APIs instead of being a real service that uses ffmpeg under the hood is the same failure mode, just one layer up. Seems like we share the same overall concern though: we want higher quality, low noise, trustworthy fundamental blocks so we can build on top without reinventing the wheel every single time. Would you say thats accurate?
Severe-Awareness829@reddit (OP)
Yes, you are spot on!
LoSboccacc@reddit
inside the messages conversation
the message conversation has at best 1mb of state.
NandaVegg@reddit
Memory is actually where the most recent LLMs improved a lot. Opus 4.6 (and many other) can handle permanent state (even without resuming session or context) just by read/write-ing md or json. And that model naturally does that with no prior instruction or mcp given, maybe you need to tell the model to write the structure down in Agents.md or SKILL.md and it will do that *almost* every time you start fresh on that directory.
Obviously there are areas you want to be mechanical, not stochastic, and this feels dumb and unsafe naturally (it should). But even the process of making it mechnical is often done by the model itself by writing scripts. I think that is what the OP's article is pointing at.
LoSboccacc@reddit
a whopping megabyte of memory, and past half that intelligence drops.
pantalooniedoon@reddit
Not disagreeing but I think what people are finding with vibecoding is that it’s easier to just rewrite entire packages or apis rather than actually find existing ones that solve your problem or just understand or improve what the existing ones do. Part of vibecoding is accessibility and until we run into clear security issues or other regressions it probably wont go back to that unless it proves much more effective.
Severe-Awareness829@reddit (OP)
code writing is a very specific example for agentic work, i am talking broadly about how communication between model and tools should be.
portmanteaudition@reddit
Aren't we already there with tools?
pantalooniedoon@reddit
Tools are what you make it though. Opus can use poorly designed tools because the model is great, it can diagnose its own issues and even solve them with just bash directly. Smaller models cant do that as well like what we run locally (so far). So you can bandage that with extremely robust tools which basically can be rewritten to be a package/program that the model can just use. That’s the difference in my mind, it’s the tool complexity and can your model handle it.
portmanteaudition@reddit
Could you elaborate?
Noiselexer@reddit
They are just api descriptions for Ai... I sure you could just wack a swagger file in Ai and tell it to use curl and it would do the same thing. Sure some mcp contain more logic but most are just api wrappers.
MMechree@reddit
I always thought of MCPs as an easier alternative, but equivalence to APIs for Agent usage. Nothing more nothing less.
rorykoehler@reddit
I don't get what people's issues are with MCP. It uses OAuth which is widely adopted. You configure it once and it just works. It's a standard protocol we can all develop against to achieve interoperability. It's completely usable. Also nothing is stopping you combining many different approaches like cli and mcp and custom tools all together in one package.
Kahvana@reddit
MCP's are great because they explicitly limit the scope of what it can do. I really don't like giving my LLMs access to powershell/bash!
Also, they are incredibly easy to write, so just write the one you need for your task. At least you know what's in there and running.
PavelPivovarov@reddit
I'm on the opposite side of this spectrum. I deliberately replaced MCP I used with CLI tool + Skill. That saves tokens, provide more flexibility and use the same standard interface we all use for ages. Plus those skills also comes with my preferences.
That is specifically useful for local LLMs where context size is limited, and huge context can impact performance.
MrShrek69@reddit
Glad people are picking up on this. I’ve always thought MCP to be really dumb and just polutes my context. Keep it simple stupid has been working really well for me. Pi coding agent has also completely changed how I think about building my agents and workflows. I don’t have to bend my workflow around the system, like in opencode or cursor. I can just build pi around my workflow instead. The tools work better and are more reliable than trad mcp
Severe-Awareness829@reddit (OP)
Exactly, let's stick to the decades tested software instead of reinventing the wheel.
a_beautiful_rhind@reddit
its cool for actual tool-tools. Don't forget that LLMs can use bash for the rest. What I'm trying to say is don't download like 50 MCP servers.
promethe42@reddit
That's true only for stateless MCP.
NandaVegg@reddit
I started to work in this industry when 2020 where people learned that vanilla GPT-3 kinda sorta works better with popular markups.
I used to dismiss those newly invented only-for-LLM implementations (I honestly thought that everything should just be json, xml or yaml for inter-LLM interface, and I think people at Microsoft at some point thought the same thing when they made inference helper that forces syntax, then Phi).
But now every redundant implementation and md comes with hidden-in-plain-sight bonus. Those extra documents and implementations would improve future LLM iteration because every frontier lab will RL their model hard on them, and larger LLMs are large enough that can memorize every pattern newly trained with. Already most agentic instructions are baked into more recent models that agentic harness with minimum system instruction (pi-coder) works very well, even the best for smaller models.
So my 2 cents: I would just use MCP and those to-be-redundant things until my latest favorite model doesn't need it anymore. But let's make those implementations small, readable and no-bloat. It will all of sudden be redundant.
Severe-Awareness829@reddit (OP)
That's an interesting take, all of the know hows will be embedded in models sooner or later so let's not worry so much about optimizing the current stuff.