Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

MCP is dead?

quandri.io

Post reply on HN
Print view View original

421–430 of 444 posts

Re: MCP is dead?

#421

Post by powersjcb »

MCP protocol layer is for all practical purposes an irrelevant implementation detail.

We need some new layer to handle things that used to be abstracted away by UIs

- filter to 6 of 50 fields for the paginated pipeline views

- show all the important fields on a detail view

- organize for understanding of fields that might have been poorly named in the public APIs

Some of this can be handled by a CLI wrapper around an API, but it really just shifts the complexity into a different system.

One thing that I haven't heard a lot of people talk about is that MCPs are often able to be far more flexible than a traditional REST api. You can ship breaking changes/renames and agents will adapt. Why should we couple the agent tooling locked 1-1 with our calcified systems?

Re: MCP is dead?

#422

Post by sunnybeetroot »

tlogan wrote: post #112
mxstbr wrote: post #22

I run the team at OpenAI that's responsible for the ChatGPT App Store, Codex plugins, and all things MCP. The thing that all these "MCP is dead" posts are missing is that whether or not MCP is used as a transport protocol is actually completely irrelevant. The reason MCP isn't dead is because practically ~every company on the planet is building an MCP server. I know this because we interact with all of them. Most of…

I would bet that MCP is going to die. The main reason is that it adds another layer (and human) that can, and probably will, get out of sync with the real-world implementation, whether that implementation is an API, web, or a CLI. AI should not be using a protocol or set of instructions that is different from what humans have access to (know and use). Sure, companies want to expose MCP servers because it is the cool…

If you don’t know how to keep your openapi spec up to date then yes you’ll struggle with keeping an MCP up to date. At the end of the day, keeping APIs in sync with SDKs, documentation, MCPs is a solved problem through automation. It’s not hard.

Re: MCP is dead?

#423

Post by sunnybeetroot »

raincole wrote: post #202
CSMastermind wrote: post #18

Was this written by AI? MCP is essentially just JSON RPC with a few special fields that must be included. I have reservations about JSON RPC, but there needs to be some 'service discovery' layer for LLMs to interface with. It needs to be available in places like websites, desktop applications, backend services, etc. The CLI is only one place that these systems interface with. Whatever you replace MCP with will be in…

Every time I read articles about MCP I feel like the internet (or HN) is having a collective stroke. People are saying API are better than MCP. But MCP is just API with some instructions for the AI to discover how to use it. Nothing more nothing less. And some people are saying we should use 'CLI'... what does it even mean? LLMs are good with common CLI tools like ffmpeg because the knowledge is solidified inside the…

Agreed, MCP works and it works well. Often I’ll wrap an API in an MCP because getting the agent to interact with an API just wastes tokens with it trailing things back and forth; MCPs just work.

Re: MCP is dead?

#424

Post by jimbokun »

827a wrote: post #402
_flux wrote: post #347

Earlier quoted context omitted.

jq cannot be just an MCP, unless it's acceptable that yuo pass all data through the context. If that's not acceptable and you want to have it as tool, then you need some other way to handle the data. I think the basic solution to this is to have a "static shell" but with modern tools for the agents, not actually executing other binaries. It could have things like jq, curl, piping and redirection to/from session files…

jq can 100% be an MCP tool. Remember: Agent tools do not have to involve a network boundary. They can be natively implemented inside the agent harness, and/or they can be provided via a local MCP server. The point of making it a tool is to tightly allowlist what the agent is capable of executing; it can only execute jq, not any shell program, and moreover it isn't allowed to do things like redirection, pipes, etc; al…

This is the first sensible thing I’ve read in defense of MCP.

However, wouldn’t a shell where all permissions are off by default, then you can enable read and write privileges to certain files and directories and executable privileges to certain binaries accomplish the same thing using UNIX permissions? Isn’t this still reinventing the wheel?

Re: MCP is dead?

#425

Post by jimbokun »

dorgo wrote: post #190
_flux wrote: post #170

Earlier quoted context omitted.

Not having access to the shell is a big hindrance. I have my agent access Gitlab and Jira via CLI tools and in so many cases jq or python is used to manipulate or combine the data into a more useful format, making use of pipes and temporary files. You can of course limit what an agent can do, most easily by not giving it access to things it shouldn't do. I suppose there are no existing easy gateway methods to grant f…

>to manipulate or combine the data into a more useful format why not build this directly into MCPs?

Go idea. We will call this new MCP “bash”. It will allow you to stream the output of one command to the input of another incrementally as the data is generated.

Re: MCP is dead?

#426

Post by falcor84 »

MatthewPhillips wrote: post #284
falcor84 wrote: post #243

Earlier quoted context omitted.

> CLIs do not run on mobile and never will Can you clarify why the never? What's the issue with giving a phone-based AI a sandboxed file system and bash shell?

How is the user installing the CLIs? Proprietary app store for each chat app?

I didn't mean that users would install them. I meant that if mcp and AI agents continue being popular, then Google and Apple could choose to provide apps with cli sandboxes with the proper permissions. It is a big change, but I just didn't understand the "never"; we've had bigger changes.

Re: MCP is dead?

#427

Post by yencabulator »

_flux wrote: post #347
827a wrote: post #314

Earlier quoted context omitted.

You’re right that having a shell is the ultimate tool, and an agent with a shell seems to perform better than one without one. But, making shells safe is really damn hard; e.g. in the context of running an agent on behalf of a SaaS customer in your AWS environment. For now some companies are accepting the performance/security tradeoff of disabling the shell and focusing on specialized tools. Remember: jq can always b…

jq cannot be just an MCP, unless it's acceptable that yuo pass all data through the context. If that's not acceptable and you want to have it as tool, then you need some other way to handle the data. I think the basic solution to this is to have a "static shell" but with modern tools for the agents, not actually executing other binaries. It could have things like jq, curl, piping and redirection to/from session files…

> Maybe even Python if it can be made safe.

https://github.com/pydantic/monty

Re: MCP is dead?

#428

Post by cindyllm »

PaulHoule wrote: post #274
didibus wrote: post #133

Earlier quoted context omitted.

A CLI needs to work on windows, mac, linux, android, iOS, etc. And it still needs some backend APIs to call. So creating one is a lot more work than just making an MCP.

That kind of code is easily portable in C or Rust or Go or Java or Python so long as it is a CLI and not GUI.

[dead]

Re: MCP is dead?

#429

Post by oliculipolicula »

PaulHoule wrote: post #274
didibus wrote: post #133

Earlier quoted context omitted.

A CLI needs to work on windows, mac, linux, android, iOS, etc. And it still needs some backend APIs to call. So creating one is a lot more work than just making an MCP.

That kind of code is easily portable in C or Rust or Go or Java or Python so long as it is a CLI and not GUI.

Again, tangential, relevant only in that CLI "portability coolness" captures only some of the meaningfulness

Having slept on the poorly made point I was trying to stick. I'm aware its still all tell no show )-:

  A comment worthy of hacker news highlights, Amish-made, fully earnest!
Would appeal to people with money, all manner of handlers, enbies born to embrace struggle, not to mention portability porn addicts. All things to all people but without the messianic contingent

  An Amish who might well have built a Space Lasers Platform  at Bell Labs!
Should perhaps be the character to learn how to play. This same Amish character would only use CLIs, on a wooden nonelectronic keyboard

I credit the obvious (to you) people here (incl you again) for this concept of an idea. Molon labe

Update: backrooms is getting serious traction in Indonesia. Ask me in a year if it was only meta-interest

Re: MCP is dead?

#430

Post by fnordpiglet »

troupo wrote: post #258
fnordpiglet wrote: post #57

Earlier quoted context omitted.

One advantage is the MCP advertises itself to the agent with its schema and api shape. Unless your CLI is in the corpus with lots of examples the agent has to learn every time. Skills help a little bit but I find the recall on skills pretty low. However I also find codex will reliably use MCPs advertised while Claude always reaches for tools like Bash() likely because it’s aligned so heavily on its own tools and is v…

> One advantage is the MCP advertises itself to the agent with its schema and api shape. So, OpenAPI/Swagger for REST? GraphQL? SOAP schemas? All of these (and more) exist. What does MCP add that these don't have?

I’m confused by the question. You listed a bunch of standards over time, all of which reach to solve a similar problem (you left off XDR/RPC, CORBA, and about 10000 others), and unironically ask why is there a n+1 standard? Are you genuinely confused?

https://xkcd.com/927

Post reply on HN