Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.

 help



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.


I get that. Should and DO are different. But you aren't addressing my Streamable HTTP question which is the heart of what I asked.

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.


There's nothing special about using http other than most corporate firewalls allow it. It's just the pragmatic choice.

This is my take as well.

Way easier to set up, centralized auth and telemetry.

Just use it for the right use cases.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: