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

MCP is a fad

tombedor.dev

Post reply on HN
Print view View original

51–60 of 129 posts

Re: MCP is a fad

#51

Post by ACCount37 »

h33t-l4x0r wrote: post #29
kburman wrote: post #18

This analysis dismisses MCP by focusing too narrowly on local file system interactions. The real value isn't just running scripts; it's interoperability. MCP allows any client (Claude, Cursor, IDEs) to dynamically discover and interact with any resource (Postgres, Slack) without custom glue code. Comparing it to local scripts is like calling USB a fad because parallel ports worked for printers. The power is standardi…

Doesn't that require a complete lack of concern on the part of the postgres side? I feel like I'm missing something in terms of why anyone would even ever allow that.

In the same way giving an LLM shell access requires a complete lack of concern.

You can give an LLM a shell into a container sandbox with basically nothing in it, or root shell on a live production server, or anything in between. Same goes for how much database access you want to give an LLM with your MCP shims.

Re: MCP is a fad

#52

Post by hahahahhaah »

m4rtink wrote: post #14

I don't think MCP is a fad - I think it is the 2020s equivalent of: - Active X - asbestos - leaded gasoline and paint - radium medicines Well, with the exception of the first 3 actually being quite useful.

How dare you mock my favourite building material.

Re: MCP is a fad

#54

Post by the_mitsuhiko »

kburman wrote: post #18

This analysis dismisses MCP by focusing too narrowly on local file system interactions. The real value isn't just running scripts; it's interoperability. MCP allows any client (Claude, Cursor, IDEs) to dynamically discover and interact with any resource (Postgres, Slack) without custom glue code. Comparing it to local scripts is like calling USB a fad because parallel ports worked for printers. The power is standardi…

> MCP allows any client (Claude, Cursor, IDEs) to dynamically discover and interact with any resource (Postgres, Slack) without custom glue code.

My agent writes its own glue code so the benefit does not seem to really exist in practice. Definitely not for coding agents and increasingly less for non coding agents too. Give it a file system and bash in a sandbox and you have a capable system. Give it some skills and it will write itself whatever is neeeded to connect to an API.

Every time I think I have a use case for MCP I discover that when I ask the agent to just write its own skill it works better, particularly because the agent can fix it up itself.

Re: MCP is a fad

#55

Post by embedding-shape »

kburman wrote: post #18

This analysis dismisses MCP by focusing too narrowly on local file system interactions. The real value isn't just running scripts; it's interoperability. MCP allows any client (Claude, Cursor, IDEs) to dynamically discover and interact with any resource (Postgres, Slack) without custom glue code. Comparing it to local scripts is like calling USB a fad because parallel ports worked for printers. The power is standardi…

> MCP allows any client (Claude, Cursor, IDEs) to dynamically discover and interact with any resource (Postgres, Slack) without custom glue code.

I don't think MCP is what actually enables that, it's LLMs that enable that. We already had the "HTTP API" movement, and it still didn't allow "without custom glue code", because someone still had to write the glue.

And even with MCP, something still has to glue things together, and it currently is the LLMs that do so. MCP probably makes this a bit easier, but OpenAPI or something else could have as easily have done that. The hard and shitty part is still being done by a LLM, and we don't need MCP for this.

Re: MCP is a fad

#57

Post by monooso »

Simon Willison made many of the same points (without the technical deep dive) back in October 2025 [1], when Anthropic announced Skills.

A couple of choice quotes, which are echoed in this new article:

> I like to joke that one of the reasons it took off is that every company knew they needed an “AI strategy”, and building (or announcing) an MCP implementation was an easy way to tick that box.

> Almost everything I might achieve with an MCP can be handled by a CLI tool instead.

[1]: https://simonwillison.net/2025/Oct/16/claude-skills/

Re: MCP is a fad

#59

Post by ACCount37 »

WJW wrote: post #30
ACCount37 wrote: post #21

Earlier quoted context omitted.

You say "have never written an RFC or an internet standard before" as if that's a disadvantage.

Only on HN is experience a disadvantage.

Experience of doing the wrong thing is.

MCP isn't a 96-page contract that covers every eventuality. It's a gentleman's agreement sealed with a firm handshake. And trying to write that 96-page contract now would be incredibly unwise.

Re: MCP is a fad

#60

Post by formerly_proven »

nomilk wrote: post #39

What do MCPs do that the CLI cannot? i.e. assuming your agent has access to the terminal, and therefore CLIs, what additional value do MCPs provide?

MCP can wrap things which have stateful processes, debuggers for example. Agents will use batch mode but it is quite limited and due to tool calls always being implemented as synchronous invocations, non-batch mode doesn’t work for tool calls. MCP solves this by giving the agent a handle it can use to refer to in multiple invocations.

Burns a lot of tokens though and if you need more than batch-mode gdb to debug something the chances of an agent solving it today are very slim.

Post reply on HN