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.
What makes you say that?
MCP: An in-depth introduction
21–30 of 96 posts
Re: MCP: An in-depth introduction
#22I 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)
look at the implementation here, 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.
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.
Re: MCP: An in-depth introduction
#23I 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)
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 websoc…
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
Re: MCP: An in-depth introduction
#24> 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…
MCP is a kitchen sink of anti-patterns. There's no way it's not forgotten in a year, just like Langchain will be
Re: MCP: An in-depth introduction
#25Earlier quoted context omitted.
look at the implementation here, 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.
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.
Except in practice it is far less convenient because it constantly breaks, with terrible error handling
Re: MCP: An in-depth introduction
#26> 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…
MCP is a kitchen sink of anti-patterns. There's no way it's not forgotten in a year, just like Langchain will be
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.
Re: MCP: An in-depth introduction
#27MCP 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.
What makes you say that?
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.
Re: MCP: An in-depth introduction
#28I 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.
[0]https://youtu.be/3NWy_sxD3Vc [1]https://github.com/microsoft/playwright-mcp [EDIT]
Re: MCP: An in-depth introduction
#29> 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…
MCP is a kitchen sink of anti-patterns. There's no way it's not forgotten in a year, just like Langchain will be
what's the problem with Langchain? still super hot to me though I did not use it myself, yet.
Re: MCP: An in-depth introduction
#30I 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)
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 websoc…
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.