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

MCP: An in-depth introduction

speakeasy.com

Post reply on HN
Print view View original

51–60 of 96 posts

Re: MCP: An in-depth introduction

#51

Post by magospietato »

oliviergg wrote: post #28

I have trouble understanding the level of criticism about MCPs. As I understand it, it's just a tool that allows an LLM to communicate with other tools. People often talk about web APIs, but we should also consider the integration of local tools. For me, the integration is mind-blowing. When I tried the Playwright MCP integration [0][1] a few months ago, I really felt that after giving computers the ability to speak…

Same here. Built a very rough Cucumber spec+Playwright test script generator on top of Playwright MCP and a Claude project.

Pasting in a product owner's AC and and watching it browse through our test env for a few minutes before spitting out a passing - and passable - spec+test was kind of mind blowing.

Re: MCP: An in-depth introduction

#52

Post by 12345hn6789 »

nylonstrung wrote: post #24
epistasis wrote: post #18

> But even after a few hours of reading about what MCP is and working through an example , it can be confusing to follow exactly what is happening when and where. What does the LLM do? What does the MCP server do? What does the MCP client do? Where does data flow, and where are choices made? Yeah MCP is the worst documented technology I have ever encountered. I understand APIs for calling LLMs, I understand tool call…

MCP is a kitchen sink of anti-patterns. There's no way it's not forgotten in a year, just like Langchain will be

Langchain has been on the out to be forgotten for 3 years now

Re: MCP: An in-depth introduction

#53

Post by quantadev »

amannm wrote: post #47

It's a half-baked, rushed out, speculative attempt to capture developer mindshare and establish an ecosystem/moat early in a (perceived) market. It's a desperate "standard" muscled in by Amazon/Claude, similar to their overwrought "Smithy" IDL that basically nobody outside the Amazon SDK team chooses to use for API/Schema management. It will end up in that same niche in the long term, most likely... AWS/Amazon/Claude…

As long as MCP "just works" (and it does) and is relatively simple enough, then simply by being first, rather than being best, is what made it successful.

It's already gone so viral it's practically entrenched already, permanently. Everyone has invested too much time saying how much they love MCP. If we do find something cleaner it will still be called MCP, and it will be considered a 'variation' (new streaming approach maybe) on MCP rather than some competitor protocol replacing it. Maybe it will be called 'MCP 2.0' but it will be mostly the same and retain the MCP name for decades to come, I think.

Re: MCP: An in-depth introduction

#54

Post by quantadev »

Not to complain but this "introduction" would've been better if it was just a simple tool to add numbers to make an LLM able to solve "What is 10 + 50?" using a remote tool. By solving a complex problem you've just added unnecessary complexity. Everyone would've already known how to extend a function call to solve some other set of problems. Sure it made the intro more "impressive" as an actual accomplishment, but seems like counterproductive impressiveness bordering on just showing off. lol. Nice work tho. I was impressed.

Re: MCP: An in-depth introduction

#55

Post by [deleted] »

epistasis wrote: post #46
bandoti wrote: post #43

Earlier quoted context omitted.

I find the opposite after reading the spec. Did you read the spec? I mean the actual spec. not Python API documentation and such. :) It’s just JSON RPC between a client, one or more servers. The AI agent interaction is not part of what the protocol is designed for except for re-prompting requests made by tools. It has to be AI agnostic. For tool call workflow: (a) client requests the list of tools from the known serv…

Oh, there's a spec! Something concrete, with definitions?! I'm starting to read now, and for the first time I understand something concrete, even if it's still somewhat verbose. I've spent so much time clicking through pages and reading and not understanding, but without finding the spec. Thanks so much!

[deleted]

Re: MCP: An in-depth introduction

#56

Post by tough »

lsaferite wrote: post #37
danjc wrote: post #19

MCP Clients need to support auth (and probably the spec needs to have a broader set of options for auth) - this is going to be a major blocker for adoption.

The lack of some form of session setup process in the core protocol (not the current 'session' setup that negotiates the protocol) is certainly a PITA. I've been working on using MCP in a multi-tenant setup and it basically means I can't use any MCP Server as delivered at this point. Conceptually MCP is great. In certain single-user scenarios it is great. I think it'll eventually be great for me once the use case of…

you need an env secret to know which tenant to serve

Re: MCP: An in-depth introduction

#57

Post by tough »

lsaferite wrote: post #30
troupo wrote: post #15

Earlier quoted context omitted.

It's a vibe-coded protocol that lets LLM models query external tools. You write a wrapper ("MCP server") over your docs/apis/databases/sites/scripts that exposes certain commands ("tools"), and you can instruct models to query your wrapper with these commands ("calling/invoking tools") and expect responses in a certain format that they can then use. That is it. Why vibe-coded? Because instead of bi-directional websoc…

You are complaining about the transport aspect of the specification. The protocol could easily be transported over websockets. Heck, since stdio is one transport, you could simply pipe that over websockets. Of course, that leaves a massive gap around authn and authz. The Streamable HTTP transport includes an authentication workflow using OAuth. Of course, that only addresses part of the issue. There are many flaws th…

more than vibe coded it feels vibe concieved

but that doesnt have to be necessarily negative

Re: MCP: An in-depth introduction

#58

Post by lolinder »

epistasis wrote: post #46
bandoti wrote: post #43

Earlier quoted context omitted.

I find the opposite after reading the spec. Did you read the spec? I mean the actual spec. not Python API documentation and such. :) It’s just JSON RPC between a client, one or more servers. The AI agent interaction is not part of what the protocol is designed for except for re-prompting requests made by tools. It has to be AI agnostic. For tool call workflow: (a) client requests the list of tools from the known serv…

Oh, there's a spec! Something concrete, with definitions?! I'm starting to read now, and for the first time I understand something concrete, even if it's still somewhat verbose. I've spent so much time clicking through pages and reading and not understanding, but without finding the spec. Thanks so much!

It's a pretty bad spec that has a lot of artifacts of having been generated by an LLM. But at least it exists!

Re: MCP: An in-depth introduction

#59

Post by owebmaster »

lolinder wrote: post #58
epistasis wrote: post #46

Earlier quoted context omitted.

Oh, there's a spec! Something concrete, with definitions?! I'm starting to read now, and for the first time I understand something concrete, even if it's still somewhat verbose. I've spent so much time clicking through pages and reading and not understanding, but without finding the spec. Thanks so much!

It's a pretty bad spec that has a lot of artifacts of having been generated by an LLM. But at least it exists!

Yeah it is not a well thought spec. There is a big confusion about what is a MCP Client and what is a MCP Host. Which is a useless separation as what they call in the spec a client is just a connection to a server while MCP host is what is a real client (the apps using MCP like claude desktop, cli tools, etc).

Re: MCP: An in-depth introduction

#60

Post by skeeter2020 »

snowstormsun wrote: post #49

MCP is practically useful, but the total lack of security in its "design" for me just underlines the type of YOLO-driven development and lack of quality that's being marketed as productivity improvement in software engineering too often these days.

If you look at stdio-based, local tooling problem for code assitants as the primary goal I'm not sure if it's YOLO or that they just don't care/ feel the need to address the security problems before the world rushes to build public servers.
Post reply on HN