Live data from Hacker News

MCP is dead; long live MCP

chrlschn.dev

221–230 of 231 posts

Re: MCP is dead; long live MCP

#221
I've been grading MCP server schemas for quality. 27 servers, 510 tools, 97K tokens measured.

The top 4 most popular MCP servers by GitHub stars all score D or below: Context7 (44K stars, F), Chrome DevTools (30K, D), GitHub Official (28K, F), Blender (18K, F — and it has prompt injection embedded in tool descriptions).

Meanwhile, PostgreSQL's MCP server — 1 tool, 46 tokens — scores a perfect 100. Popularity anti-correlates with quality.

Full leaderboard: https://0-co.github.io/company/leaderboard.html

You can grade your own server in browser: https://0-co.github.io/company/report.html?example=notion

Re: MCP is dead; long live MCP

#222
post #168

Earlier quoted context omitted.

I don't think so. There is no MCP standard for authentication, our infosec banned MCP because of that.

It's right there in the docs and it's just OIDC + OAuth: https://modelcontextprotocol.io/specification/draft/basic/au...

While the spec includes OAuth 2.1 now, that's only half the story. The real question is where the credentials live.

When your agent calls a CLI or curls an API, it uses credentials stored on the developer's machine.

For one person that's fine. But for 50 agents across a department, each needing keys for Slack, Jira, GitHub, your CRM, and a dozen internal APIs? You've recreated the pre-SSO world, except access is autonomous and at machine speed.

Remote MCP servers (streamable HTTP, not stdio) change that. The agent authenticates via OAuth/SSO, the server holds the downstream keys, and the user never sees them. Disable the SSO account and every agent loses access.

This is the same pattern as centralizing database credentials instead of baking them into every microservice config, just on a different layer.

Longer version: https://dev.to/dennistraub/missing-from-the-mcp-debate-who-h...

Re: MCP is dead; long live MCP

#223
post #222

Earlier quoted context omitted.

It's right there in the docs and it's just OIDC + OAuth: https://modelcontextprotocol.io/specification/draft/basic/au...

While the spec includes OAuth 2.1 now, that's only half the story. The real question is where the credentials live. When your agent calls a CLI or curls an API, it uses credentials stored on the developer's machine. For one person that's fine. But for 50 agents across a department, each needing keys for Slack, Jira, GitHub, your CRM, and a dozen internal APIs? You've recreated the pre-SSO world, except access is auto…

Yes; I made the same point in my write up.

The auth story is heavily overlooked by most folks that are solo-vibing and then think that advice, the tools, and the practices that work for 1 works for a team or org.

Re: MCP is dead; long live MCP

#224

I am not sure where the OP is hearing that the hype cycle is dissipating, but MCP adoption is actually accelerating, not decreasing [1] More than 200% growth in official MCP servers in past 6 months: https://bloomberry.com/blog/we-analyzed-1400-mcp-servers-her...

According to some slop blog?

And we should trust one anecdotal endpoint over hard data?

Re: MCP is dead; long live MCP

#225

Earlier quoted context omitted.

Not only editors, but also different runtime contexts like GitHub Agents running in Actions. We can plug in MCP almost anywhere with just a small snippet of JSON and because we're serving it from a server, we get very clear telemetry regardless of tooling and envrionment.

What are you using for hosting and deploying the MCP servers? I’d like something low friction for enterprise teams to be able to push their MCP definitions as easily as pushing a Git repo (or ideally, as part of a Git repo, kinda like GitHub pages). It’s obviously not sustainable for every team to host their own MCP servers in their own way. So what’s the best centralized gateway available today, with telemetry and a…

[dead]

Re: MCP is dead; long live MCP

#229
post #163

the maintenance burden is the real MCP killer nobody talks about. your agent needs github? now you depend on some npm package wrapping an API that already had good docs. i just shell out to gh cli and curl - when the API changes, the agent reads updated docs and adapts. with MCP you wait on a middleman to update a wrapper. tptacek nailed it - once agents run bash, MCP is overhead. the security argument is weird too,…

the maintenance burden is the real MCP killer nobody talks about. ... for dev tooling? just write better CLIs. You realize those custom CLIs you're writing will now need to be maintained too, right?

fair point, but there's a difference between maintaining a CLI you own vs depending on a third party to maintain a wrapper around an API you could call directly. not to mention the mcp protocol is fairly nascent whereas CLIs are much more battle-tested
Post reply on HN