> Also MCP is very obviously dead, as any of us doing heavy agentic coding know.

As someone that does heavy agentic coding (using basically all the tools), this is so far from the truth. People claiming this have probably never worked in large enterprise environments where things like authentication, RBAC, rate limiting, abuse detection, centralized management/updates/ops, etc. are a huge part of the development and deployment workflow.

In these situations you can't just use skills and cli tools without a gigantic amount of retooling and increased operational and security complexity. MCP is really useful here, and allows centralized eng and ops teams to manage their services in a way that aligns with the organizations overall posture, policies, and infrastructure.

> Google is so far behind agentic cli coding. Gemini CLI is awful.

This part I totally agree. It's really hard to express how bad it is (and it's really disappointing.)

▲

bloppe 7 hours ago | parent | next [-]

> you can't just use skills and cli tools without a gigantic amount of retooling and increased operational and security complexity

You're describing MCP. After all, MCP is just reinventing the OpenAPI wheel. You can just have a self-documenting REST API using OpenAPI. Put the spec in your context and your model knows how to use it. You can have all the RBAC and rate limiting and auth you want. Heck, you could even build all that complexity into a CLI tool if you want. MCP the protocol doesn't actually enable anything. And implementing an MCP server is exactly as complex as using any other established protocol if you're using all those features anyway

▲

whattheheckheck 6 hours ago | parent [-]

The clients for mcp can drop a url and http in the mcp.json and get access to the application. Can the client do that for every rest api?

	▲	bloppe 6 hours ago \| parent [-]
		Ya, if you just use OpenAPI. That's why I'm saying MCP adds nothing. It's just another standard for documenting APIs. There are many that have been around for a long time and that are better integrated with existing ecosystems. There's also gRPC reflection. I'm sure there are others. LLMs can use them all equally effectively.

▲

moritonal 9 hours ago | parent | prev [-]

Given MCP is supposed to just be a standardised format for self-describing APIs, why are all the features you listed MCP related things? It sounds more like it's forced the enterprise to build such features which cli tooling didn't have?

	▲	rsalus 9 hours ago \| parent \| next [-]
		mostly by virtue of being a common standard. MCP servers are primarily useful in a remote environment, where centralized management of cross-cutting concerns matters. also its really useful for integrating existing distributed services, e.g., internal data lakes. I think it's clear a self-describing CLI is optimal for local-first tooling and portability. I personally view remote MCP servers as complementary in the space.
	▲	tomnipotent 8 hours ago \| parent \| prev [-]
		MCP's can hide most things behind an API.