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

A critical look at MCP

raz.sh

Post reply on HN
Print view View original

121–130 of 348 posts

Re: A critical look at MCP

#121

Post by mondrian »

baxtr wrote: post #99
hirsin wrote: post #13

In the same way that crypto folks speedran "why we have finance regulations and standards", LLM folks are now speedrunning "how to build software paradigms". The concept they're trying to accomplish (expose possibly remote functions to a caller in an interrogable manner) has plenty of existing examples in DLLs, gRPC, SOAP, IDL, dCOM, etc, but they don't seem to have learned from any of them, let alone be aware that t…

To this date I have not found a good explanation what an MCP is. What is it in old dev language?

It's a read/write protocol for making external data/services available to a LLM. You can write a tool/endpoint to the MCP protocol and plug it into Claude Desktop, for example. Claude Desktop has MCP support built-in and automatically queries your MCP endpoint to discover its functionality, and makes those functions available to Claude by including their descriptions in the prompt. Claude can then instruct Claude Desktop to call those functions as it sees fit. Claude Desktop will call the functions and then include the results in the prompt, allowing Claude to generate with relevant data in context.

Since Claude Desktop has MCP support built-in, you can just plug off the shelf MCP endpoints into it. Like you could plug your Gmail account, and your Discord, and your Reddit into Claude Desktop provided that MCP integrations exist for those services. So you can tell Claude "look up my recent activity on reddit and send a summary email to my friend Bob about it" or whatever, and Claude will accomplish that task using the available MCPs. There's like a proliferation of MCP tools and marketplaces being built.

Re: A critical look at MCP

#122

Post by visarga »

fhd2 wrote: post #40
simonw wrote: post #10

Earlier quoted context omitted.

My theory is that a lot of the buzz around MCP is actually buzz around the fact that LLM tool usage works pretty well now. OpenAI plugins flopped back in 2023 because the LLMs at the time weren't reliable enough for tool usage to be anything more than interesting-but-flawed. MCP's timing was much better.

I'm still having relatively disastrous results compared to just sending pre curated context (i.e. calling tools deterministically upfront) to the model. Doesn't cover all the use cases, but for information retrieval stuff, the difference is pretty light and day. Not to mention the deterministic context management approach is quite a bit cheaper in terms of tokens.

I find letting the agent iterate search leads to better results. It can direct the search dynamically.

Re: A critical look at MCP

#123

Post by fendy3002 »

Opinion aside (still reading),

> Simply put, it is a JSON-RPC protocol with predefined methods/endpoints designed to be used in conjunction with an LLM.

Is a spot on / simplest explanation of MCP, wonder why nobody use that or insist that it's usb-c for AI on their tutorials! Seeing this early can makes me understand MCP in 5 minutes

Re: A critical look at MCP

#124

Post by mmcnl »

practal wrote: post #76
_raz wrote: post #21

Earlier quoted context omitted.

That's kind of my point, that the protocols complexity is hidden in py sdk making it feel easy... But taking on large tech dept

The difficult part is figuring out what kind of abstractions we need MCP servers / clients to support. The transport layer is really not important, so until that is settled, just use the Python / TypeScript SDK.

But the spec is on the transport level. So for the specification, the transport layer is very important.

Re: A critical look at MCP

#125

Post by neuroelectron »

pixl97 wrote: post #77
neuroelectron wrote: post #44

Earlier quoted context omitted.

The AI houses buying up the entire market of GPUs. Have you heard about them?

This is paranoid drivel.... Tell me which is more likely. 1. There is a cabal of companies painstakingly working together to make the most convoluted software possible from scratch so they can dominate the market. or 2. A few people threw together a bit of code to attempt to get something working without any deep engineering or systematic view of what they were trying to accomplish, getting something to work well eno…

3. The internal & enterprise models are better and not based on Python.

Re: A critical look at MCP

#126

Post by _raz »

theturtle32 wrote: post #115

Regarding the WebSocket critiques specifically, as the author of https://www.npmjs.com/package/websocket , and having participated in the IETF working group that defined the WebSocket protocol, I completely agree with this blog post's author. The WebSocket protocol is the most ideal choice for a bi-directional streaming communication channel, and the arguments listed in https://github.com/modelcontextprotocol/modelco…

Thanks, very nice! A very explanatory write-up

Re: A critical look at MCP

#127

Post by mattw1810 »

MCP should just have been stateless HTTP to begin with. There is no good reason for almost any of the servers I have seen to be stateful at the request/session level —- either the server carries the state globally or it works fine with a session identifier of some sort.

Re: A critical look at MCP

#128

Post by practal »

mmcnl wrote: post #124
practal wrote: post #76

Earlier quoted context omitted.

The difficult part is figuring out what kind of abstractions we need MCP servers / clients to support. The transport layer is really not important, so until that is settled, just use the Python / TypeScript SDK.

But the spec is on the transport level. So for the specification, the transport layer is very important.

This is the spec that counts: https://github.com/modelcontextprotocol/modelcontextprotocol...

How exactly those messages get transported is not really relevant for implementing an mcp server, and easy to switch, as long as there is some standard.

Re: A critical look at MCP

#129

Post by dend »

_raz wrote: post #96
dend wrote: post #89

Just to add one piece of clarification - the comment around authorization is a bit out-of-date. We've worked closely with Anthropic and the broader security community to update that part of MCP and implement a proper separation between resource server (RS) and authorization server (AS) when it comes to roles. You can see this spec in draft[1] (it will be there until a new protocol version is ratified). [1]: https://m…

Idk, I'm kind of agnostic and ended up throwing it in there. Regurgitating the OAuth draft don't seem that usefull imho, and why am I forced into it if I'm using http. Seems like there are plenty of usecases where un-attended thing would like to interact over http, where we usually use other things aside from OAuth. It all probably could have been replaced by - The Client shall implement OAuth2 - The Server may imple…

For local servers this doesn't matter as much. For remote servers - you won't really have any serious MCP servers without auth, and you want to have some level setting done between client and servers. OAuth 2.1 is a good middle ground.

That's also where, with the new spec, you don't actually need to implement anything from scratch. Server issues a 401 with WWW-Authenticate, pointing to metadata for authorization server locations. Client takes that and does discovery, followed by OAuth flow (clients can use many libraries for that). You don't need to implement your own OAuth server.

Re: A critical look at MCP

#130

Post by deadbabe »

Seattle3503 wrote: post #64
TZubiri wrote: post #14

"Why do I need to implement OAuth2 if I'm using HTTP as transport, while an API key is enough for stdio?" Because one is made for local and the other for connecting through the internet.

You need something like OAuth because you don't want your end users generating API keys for every service they want to use via LLM.

Maybe we should though
Post reply on HN