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

71–80 of 96 posts

Re: MCP: An in-depth introduction

#71

Post by iLoveOncall »

defaultcompany wrote: post #65

One confusing thing to me was the word "server". An "MCP server" is a server to the LLM "client". But the MCP server itself is a client to the thing it's connecting the LLM to. So it's more like an adapter or proxy. Also I was confused because often this server runs on your local system (although it doesn't have to). In my mind I thought if they're calling it a server it must be run in the cloud somewhere but that's…

MCP is supposed to support both concepts of a local and a remote server, but in practice most have opted to build local servers and the tooling basically only supports that which is a shame and, in my opinion, a nonsensical choice that basically only has downsides (you need to maintain the local server, your customers need to install it, you have to remain retro-compatible with your local server, etc.).

This just continues to reinforce my feeling that everything around vibe coding and GenAI-first work is extremely shortsighted and poor quality.

Re: MCP: An in-depth introduction

#72

Post by lolinder »

TZubiri wrote: post #68
lolinder wrote: post #6

Earlier quoted context omitted.

This is a really shallow dismissal, and I say that as someone who is outspokenly critical of MCP [0]. As you yourself say, the context is the text that is fed as input at runtime to an LLM. This text could just always come from the user as a prompt, but that's a pretty lousy interface to try to cram everything that you might want the model to know about, and it puts the onus entirely on the user to figure out what mi…

But that's not what MCP does. It is a tool created by anthropic ( 2nd most used LLM) to provide portabiliry and vendor neutrality between different LLMs. It's like terraform for LLMs. Also providing data through function calls/tool use is not context, you are overloading the term. Context is LLM context, if you fetch from a db it's something else

> But that's not what MCP does. It is a tool created by anthropic ( 2nd most used LLM) to provide portabiliry and vendor neutrality between different LLMs. It's like terraform for LLMs.

Given that your only contributions in this thread are to acknowledge your ignorance of MCP [0] and to post the summary dismissal upthread that shows your ignorance of it, it would probably behoove you to actually learn about MCP more before confidently making assertions about it. Suffice it to say that this is inaccurate and others have already explained in your "WTF is it" thread what MCP actually is.

> Also providing data through function calls/tool use is not context, you are overloading the term. Context is LLM context, if you fetch from a db it's something else

If you believe this then you don't understand how tool use is implemented. It's literally accomplished by injecting a tool's response into the context [1].

As a general life tip: most pedants are wrong most of the time. If you find yourself being pedantic, take a few steps back and double check that you're not just wrong.

[0] https://news.ycombinator.com/item?id=44011320

[1] https://platform.openai.com/docs/guides/function-calling

Re: MCP: An in-depth introduction

#73

Post by throwaway314155 »

iLoveOncall wrote: post #71
defaultcompany wrote: post #65

One confusing thing to me was the word "server". An "MCP server" is a server to the LLM "client". But the MCP server itself is a client to the thing it's connecting the LLM to. So it's more like an adapter or proxy. Also I was confused because often this server runs on your local system (although it doesn't have to). In my mind I thought if they're calling it a server it must be run in the cloud somewhere but that's…

MCP is supposed to support both concepts of a local and a remote server, but in practice most have opted to build local servers and the tooling basically only supports that which is a shame and, in my opinion, a nonsensical choice that basically only has downsides (you need to maintain the local server, your customers need to install it, you have to remain retro-compatible with your local server, etc.). This just con…

Remote server implementations would naturally invite a number of jailbreak data exfiltration exploits, no?

Re: MCP: An in-depth introduction

#74

Post by jredwards »

lsaferite wrote: post #32
jredwards wrote: post #13

Earlier quoted context omitted.

I just thought the inversion was fun. A lot of MCPs are basically wrappers around APIs, hence the comment. But certainly not all of them.

My eye twitches every time I see something like "a lot of MCPs are". It's probably a lost cause at this point, but it's an MCP Server, not an MCP. And the other side of that connection would be an MCP Client that lives in an MCP Host which almost certainly could simply be called an Agent.

You're not wrong, but you are being pretty pedantic about it. I consider myself pedantic in most circumstances but this one clearly doesn't bother me.

Re: MCP: An in-depth introduction

#75

Post by iLoveOncall »

throwaway314155 wrote: post #73
iLoveOncall wrote: post #71

Earlier quoted context omitted.

MCP is supposed to support both concepts of a local and a remote server, but in practice most have opted to build local servers and the tooling basically only supports that which is a shame and, in my opinion, a nonsensical choice that basically only has downsides (you need to maintain the local server, your customers need to install it, you have to remain retro-compatible with your local server, etc.). This just con…

Remote server implementations would naturally invite a number of jailbreak data exfiltration exploits, no?

Not more than what local servers do. You don't seem to understand what MCP is. Regardless of whether the MCP "server" is local or remote, it is JUST a wrapper around APIs. It's basically a translation layer to make your APIs adhere to the MCP spec, that's it.

Whether that wrapper's code runs on your laptop or a remote server changes nothing in terms of data exfiltration capabilities. If anything, it would make it more secure to have a remote server since at least you'd have full control over the code that's calling your API.

Re: MCP: An in-depth introduction

#78

Post by throwaway314155 »

iLoveOncall wrote: post #75
throwaway314155 wrote: post #73

Earlier quoted context omitted.

Remote server implementations would naturally invite a number of jailbreak data exfiltration exploits, no?

Not more than what local servers do. You don't seem to understand what MCP is. Regardless of whether the MCP "server" is local or remote, it is JUST a wrapper around APIs. It's basically a translation layer to make your APIs adhere to the MCP spec, that's it. Whether that wrapper's code runs on your laptop or a remote server changes nothing in terms of data exfiltration capabilities. If anything, it would make it mor…

Right but at least in the case of a local instance, the risk profile is shifted to the use of the computer. A less than ideal situation for sure, but on the other hand a user should be able to do just about anything they want to with hardware they own.

Re: MCP: An in-depth introduction

#79

Post by liuliu »

bandoti wrote: post #43
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…

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…

This blog post is miles better than MCP spec, which yes, described what you should do but doesn't really differentiate from what's beyond JSON-RPC + Auth. I think that's the point though. It is really just a RPC layer for LLM and by keeping it "generic", LLM can do anything with it.

Re: MCP: An in-depth introduction

#80

Post by progbits »

CSMastermind wrote: post #67

Anyone who has worked with LLMs for non-trival tasks know how poorly they handle JSON vs other formats (they do notably well with XML for some reason but even YAML seems to be handled fine). MCP forcing JSON for tool specifications seems like a massive mistake. Maybe Google can save us with something built on top of protobuffs.

The entire MCP mess is not even necessary with protobufs. Just give the LLM a gRPC server endpoint. Done.

No need to invent protocol for listing the tools or listing their schema. Just ask the gRPC server for the supported methods, look at the protobuf schema. This is mostly solved and supported out of the box. One potential improvement would be to have the server reply with original protobuf source, including comments, for even better semantic understanding.

No need for the absolute disaster of multiple HTTP requests + SSE, servers which need state to deal with session ids and all the problems that causes. It's just a gRPC channel and streaming methods.

And auth? Just shove credentials into the metadata. We can standardize that format, or have server reply what it supports.

Sigh... I feel like ten years ago garbage like this would be ignored or replaced with something actually sensible. But now nobody cares or feels the pain of the bad spec, they just vibe code some more mess on top of it and keep growing the ~ecosystem~ swampland.

Post reply on HN