[HN Gopher] Show HN: Ismcpdead.com - Live dashboard tracking MCP...
___________________________________________________________________
Show HN: Ismcpdead.com - Live dashboard tracking MCP adoption and
sentiment
Built this to track the ongoing debate around Model Context
Protocol - whether it's gaining real traction or just hype. Pulls
live data from GitHub, HN, Reddit and a few other sources. Curious
what the HN crowd thinks given how active the MCP discussion has
been here.
Author : sagirodin
Score : 18 points
Date : 2026-04-03 19:28 UTC (3 hours ago)
(HTM) web link (ismcpdead.com)
(TXT) w3m dump (ismcpdead.com)
| lanyard-textile wrote:
| I think MCP should not the main discussion point -- it certainly
| is the acronym that travels the world, but the real underlying
| features to track the sentiment of are "tools."
|
| You can provide JSON schemas to LLMs about functions it can call,
| and they're trained to request executions. That's the game
| changing technology. That's the future here.
|
| That's what makes claude code actually work, that's what makes a
| good chatbot useful, and that's what makes "AI" the most
| interesting right now.
|
| MCP is many things, but one very good thing is that it's merely a
| way to bring tools to your client easily -- and gate data by the
| correct level of authorization, etc.
|
| That is useful. We will likely have that in some form forever on.
| It may not be called MCP though.
| paulirwin wrote:
| 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 well. It is absurd
| to grant Claude Code permission to `az vm:*` when that includes
| everything from `az vm show` to `az vm delete`. Likewise, the
| argument that says that you should just let your LLM call APIs
| directly via curl or whatever, does not hold up well when Claude
| Code just wants raw access to all of `curl:*`.
|
| Meanwhile, MCP tools are (currently, at least in CC) managed at
| the individual tool level, which is very convenient for managing
| granular permissions.
|
| Perhaps there could be some "CTCP" (CLI tool context protocol;
| the CCP acronym does not work well) where CLI apps could expose
| their available tools to the LLM, and it could then be
| dynamically loaded and managed at a granular level. But until
| then, I'm going to keep using MCP.
| Imustaskforhelp wrote:
| 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 denied then it gives
| an error: This command isn't allowed to run.
|
| but if something like b az vm create test123 is done, then the
| command is allowed to run
|
| Someone must have made an utility similar to b, perhaps someone
| can share the links of things like this, but what are your
| thoughts on something like this paul? I definitely feel like
| convenience can be wrapped around something like this rather
| than continue to use MCP protocol.
| bizzletk wrote:
| Something like this?
| https://github.com/brycehanscomb/toolgate
| dfcowell wrote:
| 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.
| jameslk wrote:
| 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 or technical users that want agents to compose
| data or use tools programmatically, that's less valuable, but for
| most people, a one-size-fits-all MCP service that is easy to use
| is probably best
|
| There's the issues of dumping a bunch of tool definitions into
| context and eating a ton of tokens as well, but that seems more
| solvable
|
| If anything, MCP needs to evolve or MCP client tooling to
| improve, and I could see the debate going away
| dwb wrote:
| 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.
| jzymbaluk wrote:
| 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.
| tcoff91 wrote:
| A lot of people want to move away from them because they bloat
| the context a lot more than Skills do.
| _andrei_ wrote:
| 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.
| rvz wrote:
| Most of all these sources are on X (low quality garbage
| engagement bait posts) and SEO spam blogs that repeat the same
| talking points that we have all heard about MCPs. The other
| sources like Reddit, LinkedIn are non-existent on this site.
|
| You will continue to hear repeated claims of MCPs being the next
| internet, the real "Web 3.0" or it will be the new way we will be
| interacting with the web - Nope, Never and Not a chance.
|
| People talking about MCPs don't know that they are in a bubble.
| emodendroket wrote:
| I thought "who exactly is saying it's dead?" and found your
| ranking gives it a 94/100 liveliness, so I guess not that many.
| kylecazar wrote:
| It's not going to make sense for every company to _release_ an
| MCP server. If you count use /integration in their internal
| workflows and agentic dev as adoption, it's probably near 100%.
___________________________________________________________________
(page generated 2026-04-03 23:00 UTC)