Isn't MCP just an OpenAPI spec that everyone agrees on? I don't really get the confusion around it
MCP: An in-depth introduction
31–40 of 96 posts
Re: MCP: An in-depth introduction
#32Earlier quoted context omitted.
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
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.
Re: MCP: An in-depth introduction
#33Using MCP in production has a lot of tricky edge cases. This post describes some cool solutions to them
https://www.stainless.com/blog/what-we-learned-converting-co...
Re: MCP: An in-depth introduction
#34Earlier 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.
Are you sure it's not the primary antagonist from Tron (1982)?
https://en.wikipedia.org/wiki/List_of_Tron_characters#Master...
Re: MCP: An in-depth introduction
#35Earlier quoted context omitted.
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.
Are you sure it's not the primary antagonist from Tron (1982) ? https://en.wikipedia.org/wiki/List_of_Tron_characters#Master...
Hah! I'd totally forgotten about that. Thanks! Now I need to go re-watch the movie.
Re: MCP: An in-depth introduction
#36Isn't MCP just an OpenAPI spec that everyone agrees on? I don't really get the confusion around it
To be more precise, it's JSON-RPC with service discovery and cli support (CMIIW)
Re: MCP: An in-depth introduction
#37MCP 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.
The lack of some form of session setup process in the core protocol (not the current 'session' setup that negotiates the protocol) is certainly a PITA. I've been working on using MCP in a multi-tenant setup and it basically means I can't use any MCP Server as delivered at this point. Conceptually MCP is great. In certain single-user scenarios it is great. I think it'll eventually be great for me once the use case of "multi-tenant gateway service" becomes feasible.
Re: MCP: An in-depth introduction
#38I 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…
IIRC people say that MCP is initially made for CLI / local tool execution for agent-based ai like cursor.
And prople are skipping on service discovery. Making ai know what steps / operation is good.
Re: MCP: An in-depth introduction
#39Earlier 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.
The 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.
Re: MCP: An in-depth introduction
#40Earlier quoted context omitted.
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
I 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.