4 ms·

I think stateless-type MCP was already possible, eg my MCP Clock [https://github.com/firasd/mcpclock https://github.com/firasd/mcpclock]: > curl -s -X POST "

• acchow 2mo ago
  The "CLI crowd" is also primarily using LLMs on their own computer. Where they have their CLI tools. This doesn't cover the case when you're talking to an LLM from web, or via Slack or Linear, etc. There, you will want MCP so the LLM can use services on your behalf as you. That's portability.
  • drdexebtjl 2mo ago
    Why can’t the LLM you’re talking to on the web have access to your CLI tools? When you talk to an LLM on the web, the harnesses spin up a fresh environment (I would hope it’s a VM…) so that the LLM can do stuff like run arbitrary Python and Bash scripts to complete the task you asked it for. There’s no reason why you shouldn’t be able to customize this environment to add whatever CLI tools and credentials you need for the agent to act on your behalf. The UX would be exactly the same.
    • heckintime 2mo ago
      Could be more expensive to provide a computing environment.
      • drdexebtjl 2mo ago
        It can’t possibly be more expensive than doing equivalent work using context instead of RAM and inference instead of CPU. Unless we’ve got the wrong balance of compute availability and inference availability right now, but I would expect the market to stabilize at some point.
  • mhalle 2mo ago
    Skills can provide CLI tools for LLMs running on the web. It works great (I use Claude).
  • brabel 2mo ago
    Even on your own machine with CLI tools , you really think it’s a great idea to let the LLM use the CLI as if it were you, with all permissions you have without any way to differentiate between actions you have manually taken and those that the LLM did? I hope the answer is no and you sandbox the agent with its own permissions and user, but if you do that perhaps MCP does not look so bad anymore!?
    • backscratches 2mo ago
      Why would you let the llm use the CLI as you?
      • brabel 2mo ago
        Because that is convenient and everyone does it??
        • backscratches 2mo ago
          Just give it a different user with different permissions if yoirewon Linux. This is half century old tech.
• kristjansson 2mo ago
  Also: your messages causing your LLM (harness) to run CLIs on your computer? charming, thrilling, great fun. other people’s messages causing your LLM to run CLIs on your (cloud) computer? terrifying, awful, sickening, no fun at all
  • floren 2mo ago
    The LLM can't tell the difference between your messages and theirs, however many times you say "No mistakes"
    • acka 2mo ago
      Perhaps it is time to implement the lessons learned from Perl's taint checking[1], but this time for AI agent harnesses instead[2]. [1] https://en.wikipedia.org/wiki/Taint_checking https://en.wikipedia.org/wiki/Taint_checking [2] https://arxiv.org/html/2607.03423v1 https://arxiv.org/html/2607.03423v1
  • panghy 2mo ago
    [dead]
• eddythompson80 2mo ago
  I think part of the “just use a CLI” crowd might also be building similar agents as ChatGPT and Claude.ai web interface. I know at least 4 teams doing that in one company. All those teams, including ChatGPT and Claude.ai, have figured out that you will eventually need to give your agent a small sandbox Linux environment to unlock the same level of “intelligence“ those coding harness exhibit. Stitching together the results of a cli command through scripting or coding gives the agent a ton more flexibility in what it can do as it can utilize its text generation capability into executable logic. toolcalls mostly work for actions rather than complex and novel problem solving. You are making the agent represent a programming control flow through toolcalls while carrying the context between them in a lossy, nondeterministic, wasteful, slow and rigid way. It’s one thing if you want to artificially limit that agent to a very strict set of available APIs that it must use in a specific way while transferring context between them through the LLM and you don’t want to incur the cost of the extra sandbox compute. But coding harnesses have demonstrated that letting the agent write a small shell or python script can let the agents solve problems that you haven’t even really anticipated in your toolcall approach or that tool calls make prohibitively expensive or not even possible. But also the token cost tends to dwarf the sandbox compute cost, so why not pay the $0.05/hour to have a sandbox where the agent can run free when you are already paying orders of magnitude more for the tokens
  • firasd 2mo ago
    Hmm yeah but I think at some point ad-hoc code becomes a signal that something is wrong. eg. If your LLM is continuously writing python to join customers to orders at some point that's a signal that customers_aggregate('topspenders') needs to be a thing like a deterministic API call
    • drdexebtjl 2mo ago
      At that point you would add a `your-service-cli list-customers --order-by=spent` command, which would also be useful to humans and scripts, as opposed to an MCP tool call, which is only ergonomic to models.
      • 2mo ago
• drdexebtjl 2mo ago
  I don’t think the “just use a CLI” crowd really are assuming you’re a developer in a coding harness. All of those use cases you mentioned benefit from the agent having access to a temporary virtual machine with a set of standard CLI tools and the ability to write and execute arbitrary code. Most already do. ChatGPT has been running Python in the cloud to answer questions before we even had functional coding harnesses. So why not augment their repertoire of CLI tools instead of a completely new protocol?
  • firasd 2mo ago
    I guess if the agent is strongly trained to reach for the container then maybe But let’s take my MCP clock for example if you ask ChatGPT what’s the time in Tokyo it’s not even gonna think of booting up the code interpreter. It’s gonna just do web search and give you the wrong time (I just tried it and there may be an OpenAI built in widget it pops up now—but again that’s a specific tool call with an iframe output not arbitrary code)
    • drdexebtjl 2mo ago
      Because there’s probably a tool call for web search, and a tool call for arbitrary code. There’s no discovery for the CLI tools it has available unless it has already chosen to run arbitrary code. The point is that even web search should be a CLI tool, and all ChatGPT would know to do other than talk to you is how interact with a shell. Then if you ask it what’s the time in Tokyo, it would likely reach for the POSIX date command, instead of web search, because both would be equally visible.
      • firasd 2mo ago
        The amusing thing here though is that if we do high frequency container usage like you’re suggesting eventually we’re gonna reimplement MCP right. Cause then it’s like npx thiscommand —help (aka MCP tools/list) and then OAuth and all that ..
        • drdexebtjl 2mo ago
• panghy 2mo ago
  [flagged]
• ATMLOTTOBEER 2mo ago
  These days even chatting on iOS you’re getting some “vm-esque” ability for the model to run python etc They’re essentially provisioning you a temporary vm, so it’s morally equivalent to running cc on ur laptop and remote-controlling from the app, except worse So if the LLM behind the scene has its own compute environment anyway, why not just use a cli? This is imo what the cli crowd is actually assuming
• vidarh 2mo ago
  It was already possible, but it requires 1) an MCP server that terminates connections, and/or 2) for both the client and the servers to gracefully handle terminations and reconnections without bothering users with it. As for the "just use a CLI" crowd, stateless MCP servers should satisfy us too - it means providing an mcp CLI tool that provides all the benefits of a CLI with access to all the API's exposed over MCP has just become easier.
• SubiculumCode 2mo ago
  I am not sure that coding doesn't lead token usage.