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

91–96 of 96 posts

Re: MCP: An in-depth introduction

#91

Post by lsaferite »

troupo wrote: post #89
lsaferite wrote: post #30

Earlier quoted context omitted.

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…

The choice of transport is just one, quite telling, aspect of this mess. Could these commands be executed over websockets? Yes, they could. Will they? No, because the specification literally only defines two transports, and all of the clients only support those. As with any hype, the authors drink their own coolaid, invent their own terminology, and ignore literally everything that came before them. Even reading thro…

Maybe calmly look at the spec and notice that the site does actually have a clear navigation to authorization (2025-03-26 > Base Protocol > Authorization).

You clearly have no desire to objectively evaluate what the specification is trying to do and are simply disregarding all aspects of the specification as trite or pointless. As such, this will be my last response of the subject.

I encourage you to take a breath and maybe try to understand why the specification was created in the first place before dismissing it fully.

Re: MCP: An in-depth introduction

#92

Post by shepherdjerred »

yard2010 wrote: post #42
shepherdjerred wrote: post #8

Earlier quoted context omitted.

OpenAPI for LLMs is such a good way to describe it!

So.. why not use OpenAPI?

I guess there’s not really a good reason. Maybe there are specific constraints when working with LLMs? OpenAPI is quite verbose

Anyway, the technical merits don’t really matter. MCP (and any standard really) are only useful because they’re widely adopted. OpenAPI isn’t used for this, but MCP is. So, in practice, MCP is better for AI agents

Re: MCP: An in-depth introduction

#93

Post by hijodelsol »

owebmaster wrote: post #59
lolinder wrote: post #58

Earlier quoted context omitted.

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).

I had that same intial reaction but I think it makes sense if you think of it in terms of software development. There are many different MCP clients being developed that are just that - clients. They don't take care of hosting the LLM or any other functionality of the application but are meant to be plugged into existing applications to enable MCP support. So from that perspective, the difference is useful, as it refers to code developed by different people.

Re: MCP: An in-depth introduction

#94

Post by vidro3 »

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

whats wrong with langchain?

Re: MCP: An in-depth introduction

#96

Post by troupo »

lsaferite wrote: post #91
troupo wrote: post #89

Earlier quoted context omitted.

The choice of transport is just one, quite telling, aspect of this mess. Could these commands be executed over websockets? Yes, they could. Will they? No, because the specification literally only defines two transports, and all of the clients only support those. As with any hype, the authors drink their own coolaid, invent their own terminology, and ignore literally everything that came before them. Even reading thro…

Maybe calmly look at the spec and notice that the site does actually have a clear navigation to authorization (2025-03-26 > Base Protocol > Authorization). You clearly have no desire to objectively evaluate what the specification is trying to do and are simply disregarding all aspects of the specification as trite or pointless. As such, this will be my last response of the subject. I encourage you to take a breath an…

> Maybe calmly look at the spec and notice that the site does actually have a clear navigation to authorization (2025-03-26 > Base Protocol > Authorization).

Not on mobile. At least I couldn't see any obvious link to a very important part of the spec. There are circular links everywhere, none to auth.

> You clearly have no desire to objectively evaluate what the specification is trying to

I'm not questioning what it is trying to do. I'm questioning how it's doing that.

> try to understand why the specification was created in the first place before dismissing it fully.

I'm not questioning why it is trying to do. I'm questioning how it's doing that.

Stop buying into hype and marketing wholesale, and actually read what it is, and actually understand what your opponents are talking about.

Post reply on HN