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

141–150 of 444 posts

Re: MCP is dead?

#141

Post by didibus »

wild_egg wrote: post #32
rgbrenner wrote: post #16

The article has no date on it, but says deferred tool loading is a recent update that occurred after the article was written. Deferred tool loading was added in Nov 2025: https://www.anthropic.com/engineering/advanced-tool-use So these numbers are at least 7 months out of date. Why is this being posted now?

Deferred tool loading is not part of MCP. It's a Claude API special parameter that most other LLM APIs do not support.

Deferred cli/skill loading is also not part of CLIs or skills, it's all about how the coding agent/harness is implemented.

Re: MCP is dead?

#142

Post by didibus »

BeetleB wrote: post #108
wild_egg wrote: post #32

Earlier quoted context omitted.

Deferred tool loading is not part of MCP. It's a Claude API special parameter that most other LLM APIs do not support.

On the flip side, Claude is at fault in not letting you choose which tools on which MCP servers to keep in context. When I first starting using MCP about a year ago (not on Claude Code), my tools actually let me selectively turn on/off individual tools. Crazy that the company that invented MCP is not putting basic features like this in the product.

I think if you deny a tool, it won't be loaded in context at all ever, even it's name and description won't be loaded.

Re: MCP is dead?

#143

Post by 0123456789ABCDE »

ex-aws-dude wrote: post #69
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…

Isn’t that basically just a —help flag though? Still easily doable with CLI

> Isn’t that basically just a --help flag though?

mostly, but not enough — i have been experimenting with this, and what i found to help is:

  - help menu is the default, not an error message to stderr. ex: `gh pr` and `gh pr --help` are byte identical
  - if the subcommand, or the options passed are wrong, present suggestions. ex: `gh gists` -> "Did you meant this? gist"
  - the help menu should provide examples like `tldr`. sprites.dev tool `sprite` does this well, `gh` is in the training set so theirs is shorter
  - can you append the docs url to the bottom of the help menu?
  - you're serving llms.txt, right?

Re: MCP is dead?

#144

Post by didibus »

bb88 wrote: post #14

I was writing MCP servers, now I just write tools for agents to consume. It's often easier to simply write the tool you need and suggest to it to look at the tool to do that thing. I was also surprised to find out Claude knew how to use the gitlab api with pointing it at the token var in the environment. But for corporations it might make more sense to use a cli to keep the secrets separate from the agent.

> now I just write tools for agents to consume

What do you mean? Tool is a pretty generic concept.

Re: MCP is dead?

#146

Post by DonHopkins »

xyzsparetimexyz wrote: post #44

[flagged]

Then don't read the article, and don't post your Human Slop to this discussion. With your incurious attitude and performative compulsion to proudly announce your cultivated self imposed ignorance instead of contributing to the discussion, it would be best for everyone if you just deleted your account. Your best hope is to go find a job in the Trump Administration regulating AI, where you'll fit in perfectly.

Re: MCP is dead?

#147

Post by epsteingpt »

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…

Agree. But Word of caution: MCP will become the 'company wiki' of the 2020s unless you enable monetization and distribution.

Right now you have to create an MCP but v1s are always easier to maintain than v10.

We're speed running a trap.

Re: MCP is dead?

#148

Post by js4ever »

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…

Totally agree, MCP is the WAP equivalent of mobile internet access.

Re: MCP is dead?

#149

Post by meszmate »

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…

A lot of companies will never build a great CLI, and many will not prioritize a clean public API unless there is obvious demand.

Re: MCP is dead?

#150

Post by extr »

The points in this article don't really land for me. They are mostly critiques of particular MCP implementations rather than the modality itself. My impression right now:

- MCPs are great for stateless, mostly read-only interactions with document store type things. Notion/Slack/Linear are perfect use cases. I have those MCPs connected to claude code and they work great. These tools never had CLIs or super well used public APIs to begin with. MCP handles the auth for me. Cool.

- MCPs are great but not fully necessary for "function shaped" things where you're trying to run some Function and that Function has a lot of parameters with some subtlety to them and perhaps needs some examples to really help the LLM understand. Though you can get away with a skill + curl, or a hand rolled script even.

- MCPs are not so great for interacting with more complex stateful systems with large surface area. You don't want/need an AWS MCP, for example. And of course Cloudflare is the canonical example here where they do have an MCP but it has a special "Code Mode" because they have a huge product surface and a lot of state.

Most companies are somewhere in the vast space between being a document store type thing and AWS, so aren't really sure what their MCP should look like, or how customers will use it, but feel like they're missing the boat if they don't ship something. So they ship an MCP and perhaps the people who need the document type stuff load it up and get some use out of it, but others are not so satisfied. Or maybe from the other direction, people are trying to use your product but aren't super technical or don't know how to best use it with AI, but "loading up an MCP" seems like a reasonable way to start, so they ask everyone "Where's your MCP"?

I run into this at work all the time. We get a lot of requests for an MCP. But our product is not so simple to just stuff into a bunch of stateless API calls. And we question whether the people requesting the MCP really know what they want it for, exactly, other than to hook up to claude code so they can say "claude go do everything" (which is a valid sentiment, but implies a lot of work on our end to figure out how to make that work well).

Post reply on HN