261–270 of 301 posts
At the AI startup I work on, we never bothered building MCP's - it just never made sense.
And we were using skills before Claude started calling them skills, so they are kind of supported by default. Skills, CLI, Curl API requests - thats pretty much all you need.
Earlier quoted context omitted.
Strongly disagree, despite that meaning I'm swimming upstream here. Unlike cli flags, with MCP I can tune the comments for the tool more easily (for my own MCPs at least) than a cli flag. You can only put so much in a cli --help output. The error handling and debugability is also nicer. Heck, I would even favor writing an MCP tool to wrap cli commands. It's easier for me to ensure dangerous flags or parameters aren't…
Why don't you just have the agent write scripts against the APIs? The skills-based workflow doesn't confine you to bash only.
Authorization, in my opinion, is the big problem you need MCP for, though the current MCP Authorization spec still needs some refinement.
I think something I've not seen anyone mention is that MCPs make much more sense to equip agents on 3rd party platforms with the tools they need - often installing specific CLIs isn't possible and there's the question of whether you trust the platform with your CLI authentication key.
Earlier quoted context omitted.
I doesn't matter how it "should" work. In the real world you need to interact with external systems which don't have granular enough permission schemes. People out here letting Claude code run CLIs using their own user permissions are morons waiting to have their data deleted.
I get that. Should and DO are different. But you aren't addressing my Streamable HTTP question which is the heart of what I asked.
It seems that the author thinks that AI use is limited to developers, I don't understand how short slighted is the debate between CLI and MCP. Sure, CLI are more convenient, but currently most AI users consume LLM through online tools like ChatGPT A basic example: a company using ChatGPT or Claude, and wanting to connect their business tools (ex: marketing, sales, project management...). in that case MCP is perfect f…
Earlier quoted context omitted.
Because that is a consistent and reliable way of doing it? what happens when I have to use something that can't be done via cli, or if I have lots of small use cases (like I sometimes do with MCP servers - lots of tiny functions), do I create a separate readme for each of them and manage the mess? what exactly is the issue with MCP? is it too well organized? I mean technically I could be using cli tools to browse HN…
There are certainly things can't be done via CLI, or more suitable for a persistent daemon with various RPC rather than a CLI. But most things are simpler than that, and MCP is overcomplicating it. MCP does not make things more organized. Everything is a file, and the filesystem is a mature infrastructure that we can trust. I don't see how MCP can be more organized than it. curl is a great example of what CLI can do.…
However, MCP can make sense when connecting to a complex GUI app; especially one that provides visual output. The example here would be Figma.
Earlier quoted context omitted.
How do you segregate the CLI interface the LLM sees versus a human? For example if you’d like the LLM to only have access to read but not write data. One obvious fix is to put this at the authz layer. But it can be ergonomic to use MCP in this case.
Containers, virtual machines, jails. Containers have jail runtimes available. See for example gVisor/runsc.
We're entering an era where many organisations will have agentic loops running in their own backends. There's a spectrum of constraint that can be applied to these apps -- at one end claude code running unsandboxed on your laptop with all permissions off able to cook up anything it wants with bash and whatever CLIs and markdown skill documents are available, and at the other end an agentic loop running in the backend of a bank or other traditionally conservative "enterprise"/corporate organisation. Engineering teams working in that latter category are going to want to expose their own networked services to the agentic app, but they're going to want to do so in a controlled manner. And a JSON-RPC API with clearly defined single-purpose tool-calling endpoints is far, far closer to what they're looking for than the ability for the agent to do wtf it wants by using bash to script its own invocation of executables.
Earlier quoted context omitted.
that's what the MCP server is, except I don't always want a cli. If I need to call API on top of a cli tool, i don't have to have a second wrapper, or extend my existing wrapper. You're suggesting I recreate everything MCP does, just so..it's my own? MCP is just a way to use use wrappers other people have built, and to easily manage wrapping "tools", those could be cli tools, api calls, database query,etc.. cli tools…
> I don't get the issue people in this thread have with MCP, is there some burden about it I haven't ran into? It's pretty easy to set one up. Doesn’t an MCP server require running a process for the endpoint? A CLI tool doesn’t have this problem.