[dead]
MCP is dead; long live MCP
181–190 of 231 posts
Re: MCP is dead; long live MCP
#182Every single AI integration feels under-engineered (or not even engineered in case of tokenslop), as the creators put exactly the same amount of thought that $LLMOFTHEWEEK did into vomiting "You're absolutely right, $TOOL is a great solution for solving your issue!" We're yet to genuinely standardise bloody help texts for basic commands (Does -h set the hostname, or does it print the help text? Or is it -H? Does --he…
[dead]
Re: MCP is dead; long live MCP
#183[dead]
Re: MCP is dead; long live MCP
#184This seems misguided when you have to work in enterprise settings. MCP is a very natural fit for all the API auditing and domain borders that exist in enterprise environments, because it provides deterministic tooling and auditable interfaces for agents. Nobody wants an AI agent doing random API calls or shell commands.
There is no standard for MCP authentication, because of that it is e.g. blocked in my enterprise. Basically they want to avoid non-technicals installing random MCPs and exposing internals to internet.
That's not the point I wanted to make. Actually, there are "standards" if you want to consume MCP servers from enterprise apps.
Re: MCP is dead; long live MCP
#185This seems misguided when you have to work in enterprise settings. MCP is a very natural fit for all the API auditing and domain borders that exist in enterprise environments, because it provides deterministic tooling and auditable interfaces for agents. Nobody wants an AI agent doing random API calls or shell commands.
MCP is an API endpoint. If your MCP endpoints are auditable, and the rest of your APIs are not, you're doing something wrong
That's why MCP is being folded into API management.
Re: MCP is dead; long live MCP
#186Earlier quoted context omitted.
If one doesn't sandbox agent run environment then there is a problem there already.
I think a big part of why this discussion is coming up again and again is that people assume the way they are using AI is universal, but there's a bunch of different ways to leverage it. If you have an agent which runs within a product it usually cannot touch the outside world at all by design, you do not need an explicit sandbox (i.e. a VM or container) at all because it lives in an isolated environment. As soon as…
> ...people assume the way they are using AI is universal
We wanted telemetry and observability to see how agents are using tool and docs.
There's no sane way to do this as an org without MCP unless we standardize and enforce a specific toolset/harness that we wrap with telemetry. And no one wants that.
Re: MCP is dead; long live MCP
#187[dead]
Re: MCP is dead; long live MCP
#188I still think MCP is completely unnecessary (and have from the start). The article correctly points out where CLI > MCP but stops short on 2 points: 1. Documenting the interface without MCP. This problem is best solved by the use of Skills which can contain instructions for both CLIs and APIs (or any other integration). Agents only load the relevant details when needed. This also makes it easy to customize the docs f…
> This problem is best solved by the use of Skills which can contain instructions for both CLIs and APIs
> ...you can get the same benefits with a traditional centralized proxy as well. MCP doesn't inherently grant you any of those benefits.
See the three .gifs at the end of the post to see how clients use MCP prompts and resources and definitely check the specification for these two.
Re: MCP is dead; long live MCP
#189Earlier quoted context omitted.
> I have no idea what I'm missing. The questions I'd ask: - Do you work in a team context of 10+ engineers? - Do you all use different agent harnesses? - Do you need to support the same behavior in ephemeral runtimes (GH Agents in Actions)? - Do you need to share common "canonical" docs across multiple repos? - Is it your objective to ensure a higher baseline of quality and output across the eng org? - Would your wor…
What I want to know is what's the difference between a remote mcp and an api with an openapi.json endpoint for self-discovery? It's just as centralized
It's instructive to skim the top level of the MCP spec to get a sense. But you can also scroll to the end of the post and see the three .gifs there and see why MCP: because it also defines interaction models with the clients and exposes MCP prompts as `/` (slash) commands and MCP resources as `@` (at) references among other things.
You are right: MCP tools are in essence OpenAPI specs with some niceties like standardized progress reporting. But MCP is more than tools.
Re: MCP is dead; long live MCP
#190Earlier quoted context omitted.
Environments where it’s hard to install and configure cli tools and where you want oauth flows. That is mcp for coding agents is dumb. For gui apps installed at non-cli using non-permissive endpoints it makes a lot of sense.
Right, this is the part of the problem I get, but a universal meta-API seems like they're overshooting it by a lot.
The argument that mcp is poorly designed is different than “just use cli” which is further different than mcp is a dead end.
I agree mcp is bad as a protocol and likely not what solves the problem long term. But clearly the cli focus is an artifact of coding agents being the tip of the iceberg that we are seeing for llm agent use cases.