4 ms·

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

by Doublon 7mo ago

Charon77 7mo ago
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
- ekianjo 7mo ago
  Agents can't write bash correctly so... I wonder about your claim
  - anonzzzies 7mo ago
    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...
  - mannyv 7mo ago
    It can. Not sure what AI you're using, but Gemini outputs great bash. Of course you need to test it. You do have to make sure to tell it what platform you're using, because things like MacOS have different CLIs than Linux.
- deleted 7mo ago
  [deleted]
- edgyquant 7mo ago
  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
re-thc 7mo ago
> but we created MCP. Now we're wrapping MCP into CLIs... Next we'll wrap the CLIs into MCPs.
otabdeveloper4 7mo ago
MCP is a dead end, just ignore it and it will go away.
- ffsm8 7mo ago
  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 7mo ago
    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
    - wild_egg 7mo ago
      Aside from consistent auth, that's what all APIs have done for decades. Only takes 2 minutes for an agent to sort out auth on other APIs so the consistent auth piece isn't much of a selling point either.
      - ffsm8 7mo ago
        Yes, MCP could've been solved differently - eg with an extension to the openapi spec for example, at least from the perspective of REST APIs... But you're misunderstanding the selling point. The issue is that granting the LLM access to the API needs something more granular then "I don't care, just keep doing whatever you wanna do" and getting promoted every 2 seconds for the LLM to ask the permission to access something. With MCP, each of these actions is exposed as a tool and can be safely added to the "you may execute this as often as you want" list, and you'll never need to worry that the LLM randomly decides to delete something - because you'll still get a prompt for that, as that hasn't been whitelisted. This is once again solvable in different ways, and you could argue the current way is actually pretty suboptimal too... Because I don't really need the LLM to ask for permission to delete something it just created for example. But the MCP would only let me whitelist action, hence still unnecessary security prompts. But the MCP tool adds a different layer - we can both use it as a layer to essentially remove the authentication on the API you want the LLM to be able to call and greenlight actions for it to execute unattended. Again, it's not a silver bullet and I'm sure what we'll eventually settle on will be something different - however as of today, MCP servers provide value to the LLM stack. Even if this value may be provided even better differently, current alternative all come with different trade-offs And all of what I wrote ignores the fact that not every MCP is just for rest APIs. Local permissions need to be solved too. The tool use model is leaky, but better then nothing.
jamiemallers 7mo ago
[dead]

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

by Doublon 7mo ago

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

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

ekianjo 7mo ago
Agents can't write bash correctly so... I wonder about your claim
- anonzzzies 7mo ago
  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...
- mannyv 7mo ago
  It can. Not sure what AI you're using, but Gemini outputs great bash. Of course you need to test it. You do have to make sure to tell it what platform you're using, because things like MacOS have different CLIs than Linux.
deleted 7mo ago
[deleted]
edgyquant 7mo ago
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

re-thc 7mo ago

> but we created MCP. Now we're wrapping MCP into CLIs... Next we'll wrap the CLIs into MCPs.

otabdeveloper4 7mo ago

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

ffsm8 7mo ago
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 7mo ago
  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
  - wild_egg 7mo ago
    Aside from consistent auth, that's what all APIs have done for decades. Only takes 2 minutes for an agent to sort out auth on other APIs so the consistent auth piece isn't much of a selling point either.
    - ffsm8 7mo ago
      Yes, MCP could've been solved differently - eg with an extension to the openapi spec for example, at least from the perspective of REST APIs... But you're misunderstanding the selling point. The issue is that granting the LLM access to the API needs something more granular then "I don't care, just keep doing whatever you wanna do" and getting promoted every 2 seconds for the LLM to ask the permission to access something. With MCP, each of these actions is exposed as a tool and can be safely added to the "you may execute this as often as you want" list, and you'll never need to worry that the LLM randomly decides to delete something - because you'll still get a prompt for that, as that hasn't been whitelisted. This is once again solvable in different ways, and you could argue the current way is actually pretty suboptimal too... Because I don't really need the LLM to ask for permission to delete something it just created for example. But the MCP would only let me whitelist action, hence still unnecessary security prompts. But the MCP tool adds a different layer - we can both use it as a layer to essentially remove the authentication on the API you want the LLM to be able to call and greenlight actions for it to execute unattended. Again, it's not a silver bullet and I'm sure what we'll eventually settle on will be something different - however as of today, MCP servers provide value to the LLM stack. Even if this value may be provided even better differently, current alternative all come with different trade-offs And all of what I wrote ignores the fact that not every MCP is just for rest APIs. Local permissions need to be solved too. The tool use model is leaky, but better then nothing.

jamiemallers 7mo ago

[dead]