Live data from Hacker News

Show HN: Ismcpdead.com – Live dashboard tracking MCP adoption and sentiment

ismcpdead.com

11–20 of 29 posts

Re: Show HN: Ismcpdead.com – Live dashboard tracking MCP adoption and sentiment

#12

One thing that MCP solves well, that neither CLI apps (like the `gh` CLI for example) nor letting your LLM call arbitrary APIs via CURL does, is setting granular permissions per tool. Most agent frontends I've used like Claude Code only give you one level deep of CLI commands to authorize, which works fine for allowing commands like `docker build:*`. But for complex CLIs like GitHub, Azure, etc. it just doesn't scale…

can something of a cli utility be made which can deny any request from moving on, let's name this cli b which takes a user level configuration at say ~/.config or have a way to enter it via cli too or within the context of the folder which it is running in then we can have "b az vm delete test123" be run via these agents but then b checks if az vm delete command itself is allowed or not, and if it finds that its deni…

Something like this? https://github.com/brycehans/toolgate

Re: Show HN: Ismcpdead.com – Live dashboard tracking MCP adoption and sentiment

#13

One thing that MCP solves well, that neither CLI apps (like the `gh` CLI for example) nor letting your LLM call arbitrary APIs via CURL does, is setting granular permissions per tool. Most agent frontends I've used like Claude Code only give you one level deep of CLI commands to authorize, which works fine for allowing commands like `docker build:*`. But for complex CLIs like GitHub, Azure, etc. it just doesn't scale…

This is solved by the agent having its own identity and credentials. Why would you share your login and identity with your AI agent?

Access control and permissions should be handled on the backend by enforcing IAM on well-defined principals, not with MCP middleware. Claude can already bypass MCP and call APIs or use CLIs if it runs into blockers using MCP, so it’s not an effective point to implement the control.

Re: Show HN: Ismcpdead.com – Live dashboard tracking MCP adoption and sentiment

#16
post #4

I don't think MCP is going anywhere, as much as I prefer CLIs or skills generally. Where MCP really shines is reducing friction and footguns for using a service, but at the expense of less versatility and expressiveness. You get a cookie-cutter way of using tools to interact with that service, which is easy to set up, doesn't require the user to download a CLI or have their agent interact with an API For power users…

There’s nothing stopping agents from composing MCP requests and responses, or from them writing programs to process the responses. MCP tools and resources are just as composable and programmable than any CLI - and more so than most because they are structured data.

Re: Show HN: Ismcpdead.com – Live dashboard tracking MCP adoption and sentiment

#17

I don't follow the cutting edge of AI practice super closely and I'm confused. Why are people trying to say MCP is dead? I've set up a few MCP servers (mostly language servers and servers to access my company's Confluence), and they seem genuinely very useful.

Because many people have a very narrow view of what MCP is useful for. For organizational usage there isn't really an alternative.

Re: Show HN: Ismcpdead.com – Live dashboard tracking MCP adoption and sentiment

#18

One thing that MCP solves well, that neither CLI apps (like the `gh` CLI for example) nor letting your LLM call arbitrary APIs via CURL does, is setting granular permissions per tool. Most agent frontends I've used like Claude Code only give you one level deep of CLI commands to authorize, which works fine for allowing commands like `docker build:*`. But for complex CLIs like GitHub, Azure, etc. it just doesn't scale…

This is solved by the agent having its own identity and credentials. Why would you share your login and identity with your AI agent? Access control and permissions should be handled on the backend by enforcing IAM on well-defined principals, not with MCP middleware. Claude can already bypass MCP and call APIs or use CLIs if it runs into blockers using MCP, so it’s not an effective point to implement the control.

IAM is generally binary (allowed yes/no) whereas MCP usually supports more nuance (always allow/ask if risky/always ask/no)

Re: Show HN: Ismcpdead.com – Live dashboard tracking MCP adoption and sentiment

#19

One thing that MCP solves well, that neither CLI apps (like the `gh` CLI for example) nor letting your LLM call arbitrary APIs via CURL does, is setting granular permissions per tool. Most agent frontends I've used like Claude Code only give you one level deep of CLI commands to authorize, which works fine for allowing commands like `docker build:*`. But for complex CLIs like GitHub, Azure, etc. it just doesn't scale…

This is solved by the agent having its own identity and credentials. Why would you share your login and identity with your AI agent? Access control and permissions should be handled on the backend by enforcing IAM on well-defined principals, not with MCP middleware. Claude can already bypass MCP and call APIs or use CLIs if it runs into blockers using MCP, so it’s not an effective point to implement the control.

You can have agents that serve multiple different users with varying levels if permission

Re: Show HN: Ismcpdead.com – Live dashboard tracking MCP adoption and sentiment

#20
post #7

What's the purpose of this? There is no replacement for MCP. We need a protocol for calling tools that works with structured outputs, this is what we have.

in principle you could wrap an mcp's api calls in a trivial curl shell script and turn it into a skill? so are they replaceable? sure.
Post reply on HN