Top
Best
New

Posted by yarapavan 12 hours ago

You said no MCP(earendil.com)
570 points | 325 commentspage 2
zargath 1 hour ago|
not to troll, but the CLI vs. MCP feels very much like the SOAP vs. REST discussion. The "CLI works for me, so therefore MCP is sh#t"

AI/SI is having crazy impact on the entire world, and we are left with just 2 ways of doing things ? THAT is crazy to me. With all this creativity and intelligence we are down to two standards, pretty soon Thomas Watson is correct, we only have 5 computers in the world.

That being said, MCP has been truly magical for us, I just wish that the LLM labs would support their connector systems better. Too many "refresh tools" or "sign in again" ..

doublerabbit 27 minutes ago|
Welcome to the world all running jsonl.
cheema33 2 hours ago||
The shimmering effect on the web page... it does not add to the experience. It subtracts. It is very distracting. I want to read what you wrote but keep getting distracted with things moving on the screen.
magnio 10 hours ago||
I'm a bit bumped when I first saw pi is moving from bash to codemode and also adding MCP, since I thought that loses the purity and simplicity of the "use bash for everything" philosophy. However, after reading more about it, I realized codemode is just a slightly enhanced version of bash: more complex, sure, but likely more robust, secure, and efficient. For those who, like me, don't get the point of this change, here is how I understand it.

The first tool execution runtime in harnesses are direct tool calls with JSON or XML, such as the Read and Edit tools. As an escape hatch, we have Bash tool that allows arbitrary code execution on the host running the agent. The downsides of using bash (on the host) as the main tool execution runtime are:

- Syntax and obvious errors only surface at runtime

- Unergonomic orchestration of parallel and background tasks

- Verbose command output cluttering context

- Dependent on the host environment, packages versions, etc.

- No security measures by default.

To me the last point is the biggest inherent weakness, usually mitigated by creating a dedicated unprivileged user or running bash in a sandbox.

Note that direct tool calling is kind of the polar opposite on these points: syntax errors are caught early, orchestration can be done with some wrapping tools, command output is controlled, and most importantly they are more sandboxed. On the flip side, they obviously have way less power, necessitating Bash tool in the first place.

Codemode is the middle ground between these two extremes. It actually can be derived simply by one idea: what if we replace Bash by another language that can be checked for obvious errors, i.e. type checked?

Everything else falls out from there:

- Any language would do, but I think TypeScript fits the balance between safety, speed, conciseness, and popularity in training data.

- If we use TypeScript, might as well run it in a sandbox as JS runtimes have been designed with this in mind for 20 years

- Orchestration comes for free from the JS runtime. It's not more powerful, just more ergonomic.

- Since the tools are controlled by the harness and not dependent on the host, cloud agent becomes easier.

- With this in place, MCP are not very different from a tool provided to this sandboxed runtime.

Overall I find the benefits compelling enough, but we'll see if the heavily-RLed models these days will use it effectively.

crossroadsguy 5 hours ago||
Just because they were gracious enough to change their mind and talk about it in public doesn't make it universally OK.

Second, the point of Pi as a bare-bones BUT extensible harness is just that - a bare-bones harness, that can get anything one wants. Make that "thing" easy to get. Besides, bloat is bloat and every bloat is someone's must-have and vice versa.

I had also read somewhere that they have launched (already? not sure) their hosted model infra or something like OpenRouter (not sure). Nothing wrong with running a paying business along with a FOSS project but that's also there.

wren6991 12 hours ago||
> And while we could have just wired up the metadata to enable better MCP extensions, we also think that MCP with Codemode solves quite a few of the issues that it traditionally had.

There's just something that bothers me about this. Normally if LLMs want to compose multiple operations, they have the perfect tool for this: bash, or whatever other OS shell is available. It's why I was always confused by Codemode-type constructs for direct chaining of tool calls; see also the way highly-RL'd modern models will fall back to sed or python for complex file edits.

It seems like Codemode is raised here as the perfect tool for chaining or composing MCPs, but isn't that backwards? LLMs are already given the perfect tool for that, and the problem is that MCPs aren't exposed to that tool.

rcarmo 11 hours ago||
I happen to think codemode is useful, but not the full answer. I have a long and skewed history with chaining things in MCP and built a dozen or so enterprise ones (see https://taoofmac.com/space/blog/2026/04/29/2341 for notes) and it all falls back into the trade-off between agent scope/context and tool coverage: If you are using a coding agent it will have no trouble sorting out any tool regardless of how many are exposed (it's just a matter of either progressive tool disclosure or good tool metadata, since the coding agent will just go at it and expend whatever tokens are needed), whereas in a "normal", limited, scoped agent that has only a few things it needs to do (like handling a ticketing system) codemode is pretty much overkill.

Pi is primarily a coding agent, so yeah, code mode makes sense, but I've found that better MCP design saves everyone a lot of trouble and would also probably have improved the thing's reputation overall (I personally am not fond of the line protocol, would rather have protobuf and more typing, but it is what it is).

rcarmo 11 hours ago||
Addendum: My unfettered notes on chaining MCP operations are here: https://github.com/rcarmo/umcp/blob/main/docs/CHAINING.md
hobofan 12 hours ago|||
> Normally if LLMs want to compose multiple operations, they have the perfect tool for this: bash, or whatever other OS shell is available.

I many scenarios, e.g. running the harness server-side, as is the case for chat interfaces, you don't really want to expose OS shell access as that opens up a huge security attack surface.

lelanthran 11 hours ago|||
> I many scenarios, e.g. running the harness server-side, as is the case for chat interfaces, you don't really want to expose OS shell access as that opens up a huge security attack surface.

It does, but a restricted user account mitigates the large majority of those issues. A sandbox mitigates even more.

The number of remaining exploits left is probably going to be the same as the number in the harness. More, in fact, as many of them have no human review anyway.

otabdeveloper4 11 hours ago|||
You can give the LLM a bash without giving it the full /usr/bin.

That's been a trivially solved problem for decades.

hobofan 10 hours ago||
That has been one of the most common exploits for decades.
krzyk 8 hours ago|||
And as a result it is the most hardened.
otabdeveloper4 9 hours ago|||
Yes, and also MCP does literally nothing to prevent these sorts of exploits.

Like I said, AI bros vibecoding slop because they literally have no clue what they're doing.

pjmlp 11 hours ago|||
Cloud products based orchestrations with proper security mechanisms configured, don't have shell access and should only communicate over proper network mechanisms.

Rootless immutable containers without shell access, or SaaS products from multiple vendors with WebAPIs as the only touch point.

wren6991 7 hours ago||
Yeah, I'm probably over-indexing on local use cases due to my own preferences, prejudices, biases etc. For a coding agent like Pi it does seem reasonable to expect some kind of shell access though, unless some people are using it as a CLI chat client with MCP?
imtringued 5 hours ago||
Uh, you just figured out their motivation and you somehow came to the opposite conclusion?

Bash is an interface to operate Linux computers. It's not a web interface at all. It's the worst interface for the web.

Code mode is just them running JavaScript for web based APIs. They are using the web native programming language for web tasks. It's actually completely logical once that is clear.

Bash for the web is a terrible idea.

wren6991 3 hours ago||
Right, because MCP != web. In fact most of my exposure to MCP has been local tools. Also, for context, we're talking about a coding agent harness that runs on a local machine, and Codemode applies to all of its tools, not just MCP.
1vuio0pswjnm7 8 hours ago||
I don't use "AI" but I'm using "MCP" to remotely control software running on another computer on the local network by sending JSON-RPC with netcat

I send an Authorization header with a Bearer token but the procedure calls are sent in cleartext. Is this how "MCP" server is typically implemented (no encryption)

NB. I didn't write the aforementioned software implementing "MCP" server, that's someone else's work

shoo 2 hours ago|
> Is this how "MCP" server is typically implemented (no encryption).

No idea. The boring (in a positive sense) answer I'd expect for any backend API server is that encryption in transit is handled by TLS. So I'd expect either the MCP server in question can be configured to support TLS connections & refuse plaintext HTTP connections, or that for a production-like deployment it expects to be deployed behind a reverse proxy that is responsible for terminating TLS.

darepublic 10 hours ago||
> The first thing to remember is that the world is not static.

I will use this to talk to my manager about the project status

Jenk 8 hours ago||
I'm wondering why these aren't extensions rather than baked in. Extensions would be consistent with the historical development mantra of pi.
agentdev001 10 hours ago||
As many others have commented: good, I too am an mcp hater.

However- in my testing, mcp is really quite fast, and its pretty much free at this point- with frontier models. Context rot is, from what ive tested, not as much of a concern now. I genuinely was not able to hillclimb skills/extensions to beat out the speed of mcp in some cases I've been testing.

psadauskas 7 hours ago|
The advantage I see for MCP over CLIs or APIs, is that once you release the CLI/API and people start coding scripts against it, your interface is set it stone, you're never allowed to change it again, or you break everyone's scripts.

With an MCP, agents are very tolerant of changes, since each usage is fresh with no prior knowledge, so nothing to break. This allows you to experiment and iterate on the MCP, see how people use it and what gaps you still need to cover. Once it stabilizes, you can lock it down into and API/CLI interface.

estetlinus 7 hours ago|
I still don’t understand why it wouldn’t be able to navigate an API or CLI the same way it does mcp. But honestly, I don’t care anymore. The agents are so intelligent it doesn’t matter tbh.

MCP makes my boss happy so I’m happy

More comments...