Comment by CSMastermind
19 hours ago
Was this written by AI?
MCP is essentially just JSON RPC with a few special fields that must be included. I have reservations about JSON RPC, but there needs to be some 'service discovery' layer for LLMs to interface with.
It needs to be available in places like websites, desktop applications, backend services, etc. The CLI is only one place that these systems interface with.
Whatever you replace MCP with will be in a similar shape even if you specify a different communication protocol or different fields for tool discovery.
Every time I read articles about MCP I feel like the internet (or HN) is having a collective stroke.
People are saying API are better than MCP. But MCP is just API with some instructions for the AI to discover how to use it. Nothing more nothing less. And some people are saying we should use 'CLI'... what does it even mean? LLMs are good with common CLI tools like ffmpeg because the knowledge is solidified inside the weights. If I make a new CLI tool I still need to somehow teach the AI to use it. If one wants the 'teaching' part comes from a server then MCP. If one wants it local and static then skills. How could there be so many debates around these simple concepts?
My take is that most of the AI related posts are written by AI under instruction of people who hype it up but have no idea about how any of it works.
It all has some form of "the thing I'm doing is the future and everyone who doesn't join me will fall behind" energy that AI/NFT/blockchain/web3/etc. enthusiasts talk about when they're trying to sell you something or when they're trying to convince the world they really are the big money makers they claim to be.
The LLM isn't going to care about where the tokens it's inserting into the context window are coming from. For all it cares the data it's processing came in over fax and was read in with OCR.
i feel exactly the same its literally the only api standard that we truly made plug and play and even automatically oauth antenticathable with dcr and people are falling over it. also in an absolute record speed thousands of mcps.
cli’s also need to be documented and input/output typed.
its also extremly dsitributable by just pointing to an url.
cli’s are great because they are composable but i really got huge mileage out of mcps
Paradoxically, I've seen new CLI tools take on usage patterns from existing ones because of the idea of user familiarity. Even if the existing pattern sucked. I could see the same thing happening now under the idea that "the LLM already knows how to use X, so we should make our tool work like X"
I can't pipe an MCP's output to jq, and I can't ask an AI to write a python script to call an MCP.
sorry both of the things you said are false, why are they stated so confidently?
1 reply →
It's the way that it occupies the context relatively permanently, that it doesn't come along with nice install/uninstall or discovery etc. is the problem.
'Skills' should all be based on MCP, they should load on demand, be very easily manageable and discoverable by humans and by AI, and then it would work
The scope was too narrow, given how it ended up being applied.
If they layer something on top of it, it may yet be revived.
You do know MCPs are loaded on demand same as skills now right? The only place where sometimes it still uses too much context is if you have too many MCPs (same issue with skills) or some MCP is poorly designed and responds with huge description or MCP calls respond with way too much info, but skills can have this issue as well.
Yes, MCP taking the form of 'skill' because MCP serves no purpose.
The concept of 'mcp server' is a brittle abstraction that need not exist.
A 'skill' is utterly superior in every sense: a 'right sized abstraction for whatever it is you're trying to do' - that can include cli / rest - and other key bits of information.
1 reply →