We had `curl`, HTTP and OpenAPI specs, but we created MCP. Now we're wrapping MCP into CLIs...

otabdeveloper4 2 hours ago | parent | next [-]

MCP is a dead end, just ignore it and it will go away.

edgyquant 27 minutes ago | parent | next [-]

It’s not, they are a big unlock when using something like cursor or copilot. I think people who say this don’t quite know what MCP is, it’s just a thin wrapper around an API that describes its endpoints as tools. How is there not a ton of value in this?

	▲	CharlieDigital 9 minutes ago \| parent [-]
		MCP is the future in enterprise and teams. It's as you said: people misunderstand MCP and what it delivers. If you only use it as an API? Useless. If you use it on a small solo project? Useless. But if you want to share skills across a fleet of repos? Deliver standard prompts to baseline developer output and productivity? Without having to sync them? And have it updated live? MCP prompts. If you want to share canonical docs like standard guidance on security and performance? Always up to date and available in every project from the start? No need to sync and update? MCP resources. If you want standard telemetry and observability of usage? MCP because now you can emit and capture OTEL from the server side. If you want to wire execution into sandboxed environments? MCP. MCP makes sense for org-level agent engineering but doesn't make sense for the solo vibe coder working on an isolated codebase locally with no need to sandbox execution. People are using MCP for the wrong use cases and then declaring them excess when the real use case is standardizing remote delivery and of skills and resources. Tool execution is secondary.

▲

ffsm8 an hour ago | parent | prev [-]

And yet without MCP these CLI generators wouldn't be possible.

It building on top of them, because MCP did address some issues (which arguably could've been solved better with clis to begin with - like adding proper help texts to each command)... it just also introduced new ones, too.

Some of which still won't be solved via switching back to CLI.

The obvious one being authentication and privileges.

By default, I want the LLM to be able to have full read only access. This is straightforward to solve with an MCP because the tools have specific names.

With CLI it's not as straightforward, because it'll start piping etc and the same CLI is often used both for write and read access.

All solvable issues, but while I suspect CLIs are going to get a lot more traction over the next few months, it's still not the thing we'll settle on- unless the privileges situation can be solved without making me greenlight commands every 2 seconds (or ignoring their tendency to occasionally go batshit insane and randomly wipe things out while running in yolo mode)

	▲	jancurn an hour ago \| parent [-]
		Exactly. Once you start looking at MCP as a protocol to access remote OAuth-protected resources, not an API for building agents, you realize the immense value

▲

re-thc 2 hours ago | parent | prev | next [-]

> but we created MCP. Now we're wrapping MCP into CLIs...

Next we'll wrap the CLIs into MCPs.

▲

Charon77 2 hours ago | parent | prev [-]

MCP only exists because there's no easy way for AI to run commands on servers.

Oh wait there's ssh. I guess it's because there's no way to tell AI agents what the tool does, or when to invoke it... Except that AI pretty much knows the syntax of all of the standard tools, even sed, jq, etc...

Yeah, ssh should've been the norm, but someone is getting promoted for inventing MCP

▲

edgyquant 25 minutes ago | parent | next [-]

No it’s more like - because AI can’t know every endpoint and what it does, so MCP allows for injecting the endpoints and a description into context so the ai can choose the right tool without additions steps

▲

ekianjo an hour ago | parent | prev | next [-]

Agents can't write bash correctly so... I wonder about your claim

	▲	anonzzzies an hour ago \| parent [-]
		They cannot? We have a client from 25 years ago and all the devops for them are massive bash scripts; 1000s of them. Not written by us (well some parts as maintenance) and really the only 'thing' that almost always flawlessly fixes and updates them is claude code. Even with insane bash in bash in bash escaping and all kinds of not well known constructs. It works. So we habe no incentive to refactor or rewrite. We did 5 years ago and postponed as we first had to rewrite their enormous and equally badly written ERP for their factory. Maybe that would not have happened either now...

▲

an hour ago | parent | prev [-]

[deleted]