> 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 calling APIs. Yet I have read so much about MCP and have zero fucking clue except vague marketing speak. Or code that has zero explanation. What an amateur effort.
I've given up, I don't care about MCP. I'll use tool calling APIs as I currently do.
nylonstrung 4 hours ago [-]
MCP is a kitchen sink of anti-patterns. There's no way it's not forgotten in a year, just like Langchain will be
auggierose 4 hours ago [-]
The super power of MCP is that it allows you to hook up arbitrary tools using a flatrate like Claude Pro. That alone will make sure it stays.
synergy20 1 hours ago [-]
what's the problem with Langchain? still super hot to me though I did not use it myself, yet.
oliviergg 3 hours ago [-]
I have trouble understanding the level of criticism about MCPs. As I understand it, it's just a tool that allows an LLM to communicate with other tools.
People often talk about web APIs, but we should also consider the integration of local tools. For me, the integration is mind-blowing.
When I tried the Playwright MCP integration [0][1] a few months ago, I really felt that after giving computers the ability to speak or communicate, we had now given them arms.
I still get goosebumps thinking about it.
MCP Clients need to support auth (and probably the spec needs to have a broader set of options for auth) - this is going to be a major blocker for adoption.
MacsHeadroom 5 hours ago [-]
What makes you say that?
danjc 4 hours ago [-]
Most providers don't support auth in their client implementations yet. Means it's only good for calling into public data. Private enterprise data is where there's huge value.
TZubiri 11 hours 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)
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 5 hours ago [-]
I 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 4 hours ago [-]
Except in practice it is far less convenient because it constantly breaks, with terrible error handling
aryehof 7 hours ago [-]
A 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.
troupo 8 hours ago [-]
It'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.
lsaferite 56 minutes ago [-]
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 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.
nylonstrung 5 hours ago [-]
I 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
esafak 11 hours ago [-]
It's an API to expose tools to LLMs.
jredwards 9 hours ago [-]
Or... it's a tool to expose APIs to LLMs.
repeekad 9 hours ago [-]
functions 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 8 hours ago [-]
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.
lsaferite 52 minutes ago [-]
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.
AStonesThrow 41 minutes ago [-]
Are you sure it's not the primary antagonist from Tron (1982)?
But to save you the click & read: it's OpenAPI for LLMs
shepherdjerred 10 hours ago [-]
OpenAPI for LLMs is such a good way to describe it!
TZubiri 11 hours ago [-]
"“MCP is an open protocol that standardizes how applications provide context to LLMs, what’s the problem?”"
We are already off to a wrong start, context has a meaning specific to LLMs, everyone who works with LLMs knows what it means: the context is the text that is fed as input at runtime to LLM, including the current message (user prompt) as well as the previous messages and responses by the LLM.
So we don't need to read any further and we can ignore this article, and MCPs by extension, YAGNI
lolinder 11 hours ago [-]
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 might be relevant context. The premise of the Model Context Protocol (MCP) is overall sound: how do we give the "Model" access to load arbitrary details into "Context" from many different sources?
This is a real problem worth solving and it has everything to do with the technical meaning of the word "context" in this context. I'm not sure why you dismiss it so abruptly.
Yeah MCP is the worst documented technology I have ever encountered. I understand APIs for calling LLMs, I understand tool calling APIs. Yet I have read so much about MCP and have zero fucking clue except vague marketing speak. Or code that has zero explanation. What an amateur effort.
I've given up, I don't care about MCP. I'll use tool calling APIs as I currently do.
People often talk about web APIs, but we should also consider the integration of local tools. For me, the integration is mind-blowing.
When I tried the Playwright MCP integration [0][1] a few months ago, I really felt that after giving computers the ability to speak or communicate, we had now given them arms. I still get goosebumps thinking about it.
[0]https://youtu.be/3NWy_sxD3Vc [1]https://github.com/microsoft/playwright-mcp [EDIT]
Most of the material on MCP is either too specific or too in depth.
WTF is it?! (Other than a dependency by Anthropic)
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.
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.
Conversely, it allows many different LLMs to get context via many different Applications using a standard prodocol.
It addresses an m*n problem.
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.
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.
Awful case of "not invented here" syndrome
I'm personally interested in if WebTransport could be the basis for something better
https://en.wikipedia.org/wiki/List_of_Tron_characters#Master...
I like this succinct explanation.
But to save you the click & read: it's OpenAPI for LLMs
We are already off to a wrong start, context has a meaning specific to LLMs, everyone who works with LLMs knows what it means: the context is the text that is fed as input at runtime to LLM, including the current message (user prompt) as well as the previous messages and responses by the LLM.
So we don't need to read any further and we can ignore this article, and MCPs by extension, YAGNI
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 might be relevant context. The premise of the Model Context Protocol (MCP) is overall sound: how do we give the "Model" access to load arbitrary details into "Context" from many different sources?
This is a real problem worth solving and it has everything to do with the technical meaning of the word "context" in this context. I'm not sure why you dismiss it so abruptly.
[0] https://news.ycombinator.com/item?id=43949503
Agent LLMs are able to retrieve additional context and MCP servers give them specific, targeted tools to do so.