←back to thread

MCP in LM Studio

(lmstudio.ai)
225 points yags | 2 comments | | HN request time: 0.001s | source
Show context
sixhobbits ◴[] No.44384382[source]
MCP terminology is already super confusing, but this seems to just introduce "MCP Host" randomly in a way that makes no sense to me at all.

> "MCP Host": applications (like LM Studio or Claude Desktop) that can connect to MCP servers, and make their resources available to models.

I think everyone else is calling this an "MCP Client", so I'm not sure why they would want to call themselves a host - makes it sound like they are hosting MCP servers (definitely something that people are doing, even though often the server is run on the same machine as the client), when in fact they are just a client? Or am I confused?

replies(2): >>44384589 #>>44386034 #
guywhocodes ◴[] No.44384589[source]
MCP Host is terminology from the spec. It's the software that makes llm calls, build prompts, interprets tool call requests and performs them etc.
replies(1): >>44384807 #
sixhobbits ◴[] No.44384807[source]
So it is, I stand corrected. I googled mcp host and the lmstudio link was the first result.

Some more discussion on the confusion here https://github.com/modelcontextprotocol/modelcontextprotocol... where they acknowledge that most people call it a client and that that's ok unless the distinction is important.

I think host is a bad term for it though as it makes more intuitive sense for the host to host the server and the client to connect to it, especially for remote MCP servers which are probably going to become the default way of using them.

replies(1): >>44386078 #
kreetx ◴[] No.44386078[source]
I'm with you on the confusion, it makes no sense at all to call it a host. MCP host should host the MCP server (yes, I know - that is yet a separate term).

The MCP standard seems a mess, e.g take this paragraph from here[1]

> In the Streamable HTTP transport, the server operates as an independent process that can handle multiple client connections.

Yes, obviously, that is what servers do. Also, what is "Streamable HTTP"? Comet, HTTP2, or even websockets? SSE could be a candidate, but it isn't as it says "Streamable HTTP" replaces SSE.

> This transport uses HTTP POST and GET requests.

Guys, POST and GET are verbs for HTTP protocol, TCP is the transport. I guess they could say that they use HTTP protocol, which only uses POST and GET verbs (if that is the case).

> Server can optionally make use of Server-Sent Events (SSE) to stream multiple server messages.

This would make sense if there weren't the note "This replaces the HTTP+SSE transport" right below the title.

> This permits basic MCP servers, as well as more feature-rich servers supporting streaming and server-to-client notifications and requests.

Again, how is streaming implemented (what is "Streaming HTTP")?. Also, "server-to-client .. requests"? SSE is unidirectional, so those requests are happening over secondary HTTP requests?

--

And then the 2.0.1 Security Warning seems like a blob of words on security, no reference to maybe same-origin. Also, "for local servers bind to localhost and then implement proper authentication" - are both of those together ever required? Is it worth it to even say that servers should implement proper authentication?

Anyway, reading the entire documentation one might be able to put a charitable version of the MCP puzzle together that might actually make sense. But it does seem that it isn't written by engineers, in which case I don't understand why or to whom is this written for.

[1] https://modelcontextprotocol.io/specification/draft/basic/tr...

replies(1): >>44386350 #
1. diggan ◴[] No.44386350[source]
> But it does seem that it isn't written by engineers

As far as I can tell, unsurprisingly, the MCP specification was written with the help of LLMs, and seemingly hasn't been carefully reviewed because as you say, a bunch of the terms have straight up wrong definitions.

replies(1): >>44389359 #
2. kreetx ◴[] No.44389359[source]
Using LLMs is entirely fine, but poor review for a protocol definition is ..degenerate. Aren't protocols supposed to be precise?