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

MCP is dead; long live MCP

chrlschn.dev

Post reply on HN
Print view View original

61–70 of 231 posts

Re: MCP is dead; long live MCP

#61

Post by rvz »

Great article, and what I would expect from someone inspecting the hype and not jumping head first, just because influencers (paid or unpaid) are screaming for engagement just because a large X account posted their opinions.

This is one of the first posts that I've see that cuts through the hype against both MCPs and CLIs with nuance findings.

There were times where it didn't make sense for using MCPs (such as connecting it to a database) and CLIs don't make sense at all for suddenly generating them for everything. It just seems like the use-case was a solution in search of a problem on top of a bad standard.

But no-one could answer "who" was the customer of each of these, which is why the hype was unjustified.

Re: MCP is dead; long live MCP

#62

Post by simianwords »

CharlieDigital wrote: post #57
simianwords wrote: post #45

Earlier quoted context omitted.

I would want to know what point I missed. I can have 100 CLI's but not 100 MCP tools. 100 MCP tools will bloat the context whereas 100 CLI's won't. Which part do you disagree with?

1. The part where you are providing 100 tools instead of a few really flexible tools 2. The part where you think your agent is going to know how to use 100 CLI tools that are not already in its training dataset without using extra turns walking the help content to dump out command names and schemas 3. The part where, without a schema defining the inputs, the LLM wastes iterations trying to correct the input format. 4…

> The part where you are providing 100 tools instead of a few really flexible tools

I'm not sure how that solves the issue. The shape of each individual tool will be different enough that you will need different schema - something you will be passing each time in MCP and something you can avoid in CLI. Also, CLI's can also be flexible.

> The part where you think your agent is going to know how to use 100 CLI tools that are not already in its training dataset without using extra turns walking the help content to dump out command names and schemas

By CLI's we mean SKILLS.md so it won't require this hop.

> The part where, without a schema defining the inputs, the LLM wastes iterations trying to correct the input format.

What do we lose by one iteration? We lose a lot by passing all the tool shapes on each turn.

> The part where, not having the full picture of the tools, your odds of it picking the same tools or the right tools is completely gambling that it outputs the right keywords to trigger the tool to be used.

we will use skills

> The part where you forgot to mention that for your agent to know that your 100 CLI tools exist, you had to either provide it in context directly, provide it in context in a README.md, or have it output the directory listing and send that off to the LLM to evaluate before picking the tool and then possibly expanding the man pages for several tools and sub commands using several turns.

skills

Re: MCP is dead; long live MCP

#64

Post by whattheheckheck »

chatmasta wrote: post #17
CharlieDigital wrote: post #10

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…

ROSA

https://docs.aws.amazon.com/whitepapers/latest/overview-depl...

it should be part of your app and coordinated in a way that everyone in the enterprise can find all the available mcps. Like backstage or something

Re: MCP is dead; long live MCP

#65

Post by avereveard »

ambicapter wrote: post #20
0xbadcafebee wrote: post #12

MCP is a fixed specification/protocol for AI app communication (built on top of an HTTP CRUD app). This is absolutely the right way to go for anything that wants to interoperate with an AI app. For a long time now, SWEs seem to have bamboozled into thinkg the only way you can connect different applications together are "integrations" (tightly coupling your app into the bespoke API of another app). I'm very happy some…

If AI is AI, why does it need a protocol to figure out how to interact with HTTP, FTP, etc.? MCP is a way to quickly get those integrations up and running, but purely because the underlying technology has not lived up to its hyped abilities so far. That's why people think of MCP as a band-aid fix.

C

each ai need context management per conversation this is something that would be very clunky to replicate on top of http or ftp (as in requiring side channel information due session and conversation management)

Everyone looks at api and sure mcp seem redundant there but look at agent driving a browser the get dom method depends on all the action performed from when the window opened and it needs to be per agent per conversation

Can you do that as rest sure sneak a session and conversation in a parameter or cookie but then the protocol is not really just http is it it's all this clunky coupling that comes with a side of unknowns like when is a conversation finished did the client terminate or were just between messages and as you go and solve these for the hundredth time you'd start itching for standardization

Re: MCP is dead; long live MCP

#67

Post by 8note »

moralestapia wrote: post #18
fartfeatures wrote: post #6

Earlier quoted context omitted.

All the code I work on now has an MCP interface so that the LLM can debug more easily. I'd argue it is as important as the UI these days. The amount of time it has saved me is unreal. It might be worth investing a very small amount of your time in it to see if it is a good fit. Even a poor protocol can provide useful functionality.

Our workflows must be massively different. I code in 8 languages, regularly, for several open source and industry projects. I use AI a lot nowadays, but have never ever interacted with an MCP server. I have no idea what I'm missing. I am very interested in learning more about what do you use it for.

Its very similar to the switch from a text editor + command line, to having an IDE with a debugger.

the AI gets to do two things:

- expose hidden state - do interactions with the app, and see before/after/errors

it gives more time where the LLM can verify its own work without you needing to step in. Its also a bit more integration test-y than unit.

if you were to add one mcp, make it Playwright or some similar browser automation mcp. Very little has value add over just being able to control a browser

Re: MCP is dead; long live MCP

#68

Post by charcircuit »

>The LLM has no way of knowing which CLI to use and how it should use it…unless each tool is listed with a description somewhere either in AGENTS|CLAUDE.md or a README.md

This is what the skill file is for.

>Centralizing this behind MCP allows each developer to authenticate via OAuth to the MCP server and sensitive API keys and secrets can be controlled behind the server

This doesn't require MCP. Nothing is stopping you from creating a service to proxy requests from a CLI.

The problem with this article is it doesn't recognize that skills is a more general superset compared with MCP. Anything done with MCP could have an equivalent done with a skill.

Re: MCP is dead; long live MCP

#69

Post by kybernetikos »

fartfeatures wrote: post #6
codemog wrote: post #2

As soon as MCP came out I thought it was over engineered crud and didn’t invest any time in it. I have yet to regret this decision. Same thing with LangChain. This is one key difference between experienced and inexperienced devs; if something looks like crud, it probably is crud. Don’t follow or do something because it’s popular at the time.

All the code I work on now has an MCP interface so that the LLM can debug more easily. I'd argue it is as important as the UI these days. The amount of time it has saved me is unreal. It might be worth investing a very small amount of your time in it to see if it is a good fit. Even a poor protocol can provide useful functionality.

I've just been discovering this pattern too. It's made a huge difference. Trying to get Claude to remote control an app for testing via the various other means was miserable and unreliable.

I got it to build an MCP server into the app that supported sending commands to allow Claude to interact with it as if it was a user, including keypresses and grabbing screenshots, and the difference was immediate and really beneficial.

Visual issues were previously one of the things it would tend to struggle with.

Re: MCP is dead; long live MCP

#70

Post by 8note »

8n4vidtmkvmk wrote: post #55
winrid wrote: post #22

Earlier quoted context omitted.

Many products provide MCP servers to connect LLMs. For example I can have claude examine things through my ahrefs account without me using the UI etc

That's also one of the things that worries me the most. What kind of data is being sent to these random endpoints? What if they to rogue or change their behavior? A static set of tools is safer and more reliable.

mcp is generally a static set of tools, where auth is handled by deterministic code and not exposed to the agent.

the agent sees tools as allowed or not by the harness/your mcp config.

For the most part, the same company that you're connecting to is providing the mcp, so its not having your data go to random places, but you can also just write your own. its fairly thin wrappers of a bit of code to call the remote service, and a bit of documentation of when/what/why to do so

Post reply on HN