3 ms·
I feel like I need the opposite, a cursory view, or at least a definition. Most of the material on MCP is either too specific or too in depth. WTF is it?! (Ot
by TZubiri 1y ago
I feel like I need the opposite, a cursory view, or at least a definition.
Most of the material on MCP is either too specific or too in depth.
WTF is it?! (Other than a dependency by Anthropic)
- mdaniel 1y agoThis is a VFAQ https://hn.algolia.com/?q=what+is+mcp https://hn.algolia.com/?q=what+is+mcp But to save you the click & read: it's OpenAPI for LLMs
- shepherdjerred 1y agoOpenAPI for LLMs is such a good way to describe it!
- lsaferite 1y agoSeems apt to me as well. Before the whole "just use OpenAPI" crowd arrives, the point is that LLMs work better with curated context. An OpenAPI server not designed for that will quickly flood an LLM context window.
- yard2010 1y agoSo.. why not use OpenAPI?
- shepherdjerred 1y agoI 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
- skeeter2020 1y agoit's so apt that one of the most common question/statements I hear is why not use OpenAPI? I don't know the answer. Or WTF is streaming HTTP? Sure feels like we're trying to reinvent web sockets. It must be either #notinventedhere or while the genius devs build the LLMs the interns do the documentation and SDKs
- esafak 1y agoIt's an API to expose tools to LLMs.
- jredwards 1y agoOr... it's a tool to expose APIs to LLMs.
- repeekad 1y agofunctions that an LLM can use in its reasoning are called "tools", so the prior is probably more correct in the sense that an API can be used to provide the LLM tools
- jredwards 1y agoI just thought the inversion was fun. A lot of MCPs are basically wrappers around APIs, hence the comment. But certainly not all of them.
- lsaferite 1y agoMy 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.
- AStonesThrow 1y agoAre you sure it's not the primary antagonist from Tron (1982)? https://en.wikipedia.org/wiki/List_of_Tron_characters#Master_Control_Program https://en.wikipedia.org/wiki/List_of_Tron_characters#Master...
- lsaferite 1y agoHah! I'd totally forgotten about that. Thanks! Now I need to go re-watch the movie.
- jredwards 1y agohttps://youtu.be/74c1ByGvFPE?si=S-5oBO8ptL_7WmQ9 https://youtu.be/74c1ByGvFPE?si=S-5oBO8ptL_7WmQ9 I like this succinct explanation.
- troupo 1y agoIt'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 websockets the protocol uses unidirectional server-side events, so you need to send requests to a separate endpoint and then listen to the SSE hoping for an answer. There's also non-existent authentication.
- nylonstrung 1y agoI see zero reason they couldn't have used standard websockets and made it simpler and more robust. Awful case of "not invented here" syndrome I'm personally interested in if WebTransport could be the basis for something better
- lsaferite 1y agoYou 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 that need improvement in MCP, but railing against the current transports by using a presumably denigratory term ("vibe-coded") isn't helpful. Your "that is it" stops at talking about one single aspect of the protocol. On the server side you left out resources and prompts. On the client side you left out sampling, which I find to be a very interesting possibility. I think MCP has many warts that need addressing. I also think it's a good start on a way to standardize connections between tools and agents.
- aryehof 1y agoA standard protocol that allows many different Applications to provide context to many different LLMs. Conversely, it allows many different LLMs to get context via many different Applications using a standard prodocol. It addresses an m*n problem.
- kristopolous 1y agolook at the <client> implementation here, https://modelcontextprotocol.io/quickstart/client https://modelcontextprotocol.io/quickstart/client that's the missing piece in most of these description. You send off a description of the tools, the model decides if it wants to use one, then you run it with the args, send it back to the context and loop.
- fhd2 1y agoI found that the other day and finally got what MCP is. Kinda just a convenience layer for hooking up an API via good "old" tool use. Unless I'm missing something major, it's just marginally more convenient than just hooking up tool calls for, say, OpenAPI. The power is probably in the hype around it more than it's on technical merits.
- nylonstrung 1y agoExcept in practice it is far less convenient because it constantly breaks, with terrible error handling
- lsaferite 1y agoI had a fun one yesterday. The `mcp-atlassian` server failed trying to create multiple Jira tickets. The error response (and error logs) was just a series of newlines (one for each ticket we wanted to create). Turned out the issue was the LLM decided to mis-capitalize the project code. My best guess is it read the product name, which has the same letters but not fully uppercase, and used that instead of the Jira project code which was also provided in the context.
- lsaferite 1y agoThe ideal is that you can simply connect to whatever MCP Server endpoint you need, without needing to code your own tools. The reality is that the space is still really young and people are figuring things out as they go. The number of people that have no real clue what they are doing that are jumping in is shocking. Relatedly, the number of people that can't see the value in a protocol specifically designed to work with LLM Tool Calling is equally shocking. Can you write code that glues an OpenAPI Server to an LLM-based Tool Calling Agent? 100%! Will that setup flood the context window of the LLM? Almost certainly. You need to write code to distill those OpenAPI responses down to some context the LLM can work with, respecting the limited space for context. Great, now you've written a wrapper on that OpenAPI server that does exactly that. And you've written, in essence, a basic MCP Server. Now, if someone were to write an MCP Server that used an LLM (via the LLM Client 'sampling' feature) to consume an OpenAPI Server Spec and convert it into MCP Tools dynamically, THAT would be cool. Basically a dynamic self-coding MCP Server.