3 ms·
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 htt
by bmurphy1976 8mo ago
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.
- 0x696C6961 8mo agoI 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.
- bmurphy1976 8mo agoI get that. Should and DO are different. But you aren't addressing my Streamable HTTP question which is the heart of what I asked.
- buremba 8mo agoCLI 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.
- bmurphy1976 8mo agoThat'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.
- 0x696C6961 7mo agoThere's nothing special about using http other than most corporate firewalls allow it. It's just the pragmatic choice.