5 ms·

As someone who does both, I have to say that the only reason I am writing MCP stuff is that all the user-side tools seem to support it. And the moment we, as a

by rcarmo 1y ago

As someone who does both, I have to say that the only reason I am writing MCP stuff is that all the user-side tools seem to support it. And the moment we, as an industry, settle on something sane, I will rip out the whole thing and adopt that, because MCP brings _nothing_ to the table that I could not do with a "proper" API using completely standard tooling. Then again, I have run the whole gamut since the EDI and Enterprise JavaBeans era, XML-RPC, etc. - the works. Our industry loves creating new API surfaces and semantics without a) properly designing them from the start and b) aiming for a level of re-use that is neither pathological nor wasteful of developer time, so I'm used to people from "new fields of computing" ignoring established wisdom and rolling their own API "conventions". But, again, the instant something less contrived and more integratable comes along, I will gleefully rm -rf the entire thing and move over, and many people in the enterprise field feel exactly the same - we've spent decades builting API management solutions with proper controls, and MCP bodges all of that up.

alfalfasprout 1y ago
> And the moment we, as an industry, settle on something sane, I will rip out the whole thing and adopt that, because MCP brings _nothing_ to the table that I could not do with a "proper" API using completely standard tooling. 100%. I suppose I understand MCP for user-side tooling but people seem to be reinventing the wheel because they don't understand REST. making REST requests with a well defined schema from an LLM is not all that hard.
- OJFord 1y ago
  I don't even mind it existing, it's just the way it's presented/documented/talked about like it's some special novel important concept that baffles me, and I think makes it more confusing for developer newcomers (but fine or maybe even helpful for not-particularly-technical but AI-keen/'power' users).
  - visarga 1y ago
    MCP is really a great leap because LLMs orchestrate across a collection of tools instead of running a scripted flow. The most obvious example is deep research, where the LLM sends initial queries, reads, then generates new queries and loops until it finds what it needs. This dynamic orchestration of the search tool is almost impossible to do in a scripted way. And it shows where the MCP value is - you just write simple tools, and AI handles the contextual application. You just make the backend, the front end is the LLM with human in the loop. I made an MCP with 2 tools - generate_node and search, and with it Claude Desktop app can create a knowledge graph complete with links and everything. It scales unbounded by context size but is read/write and smarter than RAG because it uses graph structure not just embeddings. I just made the reading and writing tools, the magic of writing the nodes, linking them up, searching and analyzing them is due to AI. And again, Claude can be very efficient at wielding these tools with zero effort on my part. That is the value of MCP.
    - crashabr 1y ago
      Could you elaborate on why the graph structure is better than embeddings? Is it for a specific use case?
    - simiones 1y ago
      MCP is a detail here. The exact same thing would happen if generate_node and search were exposed as REST endpoints, if Claude Desktop had used REST instead of MCP.
      - bboygravity 1y ago
        Isn't part of the issue that LLM's are relatively bad at REST and json and all that? I remember like 2 years ago there was big hype/revolution around ChatGPT finally being able to return ONLY valid json when you asked it to. So apparently LLMs are not that good at scripting without mistakes. Having said that, I honestly have no clue what MCP looks like or is lol :p
        simiones 1y ago
        MCP is a form of JSON-RPC over HTTP, so I don't think it has anything to do with that.
  - fennecbutt 1y ago
    Yes, I've had to deal with this at work as well. Much talk about MCP as if it's some mystical magical wonder, and not just concatenating a bunch of json to your prompt.
- jmward01 1y ago
  I personally wouldn't be surprised if the http calling abilities of LLMs end up killing MCP, or at least greatly reducing its use. If you train LLMs to start interacting with REST APIs as a great way to make them do more then a lot of the MCP use cases go away.
  - cable 1y ago
    HATEOAS FTW
  - nunodonato 1y ago
    I have a tool that builds HTTP requests. LLMs can use that just fine, IF they know the API spec they should connect to. And that is the problem. If you are then required to pass the specs of dozens of APIs, you are polluting the context with too much useless info. MCP simplifies that
    - simiones 1y ago
      You also need an MCP schema to understand what the MCP server can actually do, there is no free lunch here.
      - nunodonato 1y ago
        yes, but in terms of token size its WAY cheaper for the AI to handle that than an OpenAPI spec
        miningape 1y ago
        Isn't this more a limitation of the OpenAPI spec? Something like GraphQL would probably work much better
  - v3ss0n 1y ago
    LLM already exist that capabilities since chatgpt GPT3.5 Just they don't have tools and then, tools are simply introduced by tool calling specs and it works fine already. MCP is a wrapper around that specs nothing new
- jon-wood 1y ago
  I find it kind of sad that now we finally have tooling which could make use of HATEOS[1] style REST APIs, which are technically self-documenting and in practice never really took off because you need to understand the API to write a client for it, everyone ran off and designed something else instead. [1] https://en.wikipedia.org/wiki/HATEOAS https://en.wikipedia.org/wiki/HATEOAS
cranium 1y ago
Looks like the GraphQL beginnings, it feels fresh now and the AI products kind of nudge everything that way but fundamentally the main point is being able to package an API into a standard format, with documented endpoints, support for authentication, and different transports. Nothing that couldn't be solved by a well designed REST API with Swagger documentation (and authentication, and websockets), but by being the same interface for all APIs it reduces the burden on the LLM.
- _heimdall 1y ago
  You wouldn't even need Swagger if we actually used REST. Swagger is only around because we abandoned REST for RPC.
  - zo1 1y ago
    REST is just like scrum/agile. There is apparently some sort of "standard" but really anything goes and everyone does whatever they want.
    - _heimdall 1y ago
      What do you mean? REST was really clearly defined in Roy Fielding's dissertation when he proposed the term in the first place. I agree people do whatever they want and call it REST, but that's not because of a lack of definition in what their term.
- hobofan 1y ago
  > but by being the same interface for all APIs it reduces the burden on the LLM It doesn't reduce the burden for the LLM, as the LLM isn't the piece of software directly interfacing with the MCP server. It reduced the burden for people building clients that call LLMs and have to convert external interfaces into tool calls etc..
v3ss0n 1y ago
I am looking into ACP and it looks something more solid compared to MCP which is like an intern project. What do you think?
Gerardo1 1y ago
> because MCP brings _nothing_ to the table that I could not do with a "proper" API using completely standard tooling. This is what drives me crazy and has stopped my tinkering with MCP in its tracks: what is the point? It's not bringing anything new. It's usually not easier to set-up than what you're describing. Or, if you absolutely must have an LLM in the mix, normal function calling does just as well as MCP. It's a real, "I feel like I'm taking crazy pills" moment: there's all this hype and bluster and "wow look at this", but there is no "this". Everyone's talking about "it can do" and "it'll be amazing when", but there's nothing actually built and present and ready that is impressive.
- zingababba 1y ago
  It's not really MCP that is 'this', MCP is just the glue that makes the NLP as frontend easy to conceptualize in terms of application. Everyone is getting excited because it's now relatively obvious how you can go from talking to LLM -> large orchestration happening, even though you could do this already with langchain or whatever. MCP is basically just a protocol you can bring into the context window, do your LLM coding magic, then start up your MCP server and test your tool chain for your NLP as frontend stuff. The only difference is now it's not deterministic so stuff will get randomly fucked up.

by rcarmo 1y ago

alfalfasprout 1y ago

> And the moment we, as an industry, settle on something sane, I will rip out the whole thing and adopt that, because MCP brings _nothing_ to the table that I could not do with a "proper" API using completely standard tooling. 100%. I suppose I understand MCP for user-side tooling but people seem to be reinventing the wheel because they don't understand REST. making REST requests with a well defined schema from an LLM is not all that hard.

OJFord 1y ago
I don't even mind it existing, it's just the way it's presented/documented/talked about like it's some special novel important concept that baffles me, and I think makes it more confusing for developer newcomers (but fine or maybe even helpful for not-particularly-technical but AI-keen/'power' users).
- visarga 1y ago
  MCP is really a great leap because LLMs orchestrate across a collection of tools instead of running a scripted flow. The most obvious example is deep research, where the LLM sends initial queries, reads, then generates new queries and loops until it finds what it needs. This dynamic orchestration of the search tool is almost impossible to do in a scripted way. And it shows where the MCP value is - you just write simple tools, and AI handles the contextual application. You just make the backend, the front end is the LLM with human in the loop. I made an MCP with 2 tools - generate_node and search, and with it Claude Desktop app can create a knowledge graph complete with links and everything. It scales unbounded by context size but is read/write and smarter than RAG because it uses graph structure not just embeddings. I just made the reading and writing tools, the magic of writing the nodes, linking them up, searching and analyzing them is due to AI. And again, Claude can be very efficient at wielding these tools with zero effort on my part. That is the value of MCP.
  - crashabr 1y ago
    Could you elaborate on why the graph structure is better than embeddings? Is it for a specific use case?
  - simiones 1y ago
    MCP is a detail here. The exact same thing would happen if generate_node and search were exposed as REST endpoints, if Claude Desktop had used REST instead of MCP.
    - bboygravity 1y ago
      Isn't part of the issue that LLM's are relatively bad at REST and json and all that? I remember like 2 years ago there was big hype/revolution around ChatGPT finally being able to return ONLY valid json when you asked it to. So apparently LLMs are not that good at scripting without mistakes. Having said that, I honestly have no clue what MCP looks like or is lol :p
      - simiones 1y ago
        MCP is a form of JSON-RPC over HTTP, so I don't think it has anything to do with that.
- fennecbutt 1y ago
  Yes, I've had to deal with this at work as well. Much talk about MCP as if it's some mystical magical wonder, and not just concatenating a bunch of json to your prompt.
jmward01 1y ago
I personally wouldn't be surprised if the http calling abilities of LLMs end up killing MCP, or at least greatly reducing its use. If you train LLMs to start interacting with REST APIs as a great way to make them do more then a lot of the MCP use cases go away.
- cable 1y ago
  HATEOAS FTW
- nunodonato 1y ago
  I have a tool that builds HTTP requests. LLMs can use that just fine, IF they know the API spec they should connect to. And that is the problem. If you are then required to pass the specs of dozens of APIs, you are polluting the context with too much useless info. MCP simplifies that
  - simiones 1y ago
    You also need an MCP schema to understand what the MCP server can actually do, there is no free lunch here.
    - nunodonato 1y ago
      yes, but in terms of token size its WAY cheaper for the AI to handle that than an OpenAPI spec
      - miningape 1y ago
        Isn't this more a limitation of the OpenAPI spec? Something like GraphQL would probably work much better
- v3ss0n 1y ago
  LLM already exist that capabilities since chatgpt GPT3.5 Just they don't have tools and then, tools are simply introduced by tool calling specs and it works fine already. MCP is a wrapper around that specs nothing new
jon-wood 1y ago
I find it kind of sad that now we finally have tooling which could make use of HATEOS[1] style REST APIs, which are technically self-documenting and in practice never really took off because you need to understand the API to write a client for it, everyone ran off and designed something else instead. [1] https://en.wikipedia.org/wiki/HATEOAS https://en.wikipedia.org/wiki/HATEOAS

cranium 1y ago

Looks like the GraphQL beginnings, it feels fresh now and the AI products kind of nudge everything that way but fundamentally the main point is being able to package an API into a standard format, with documented endpoints, support for authentication, and different transports. Nothing that couldn't be solved by a well designed REST API with Swagger documentation (and authentication, and websockets), but by being the same interface for all APIs it reduces the burden on the LLM.

_heimdall 1y ago
You wouldn't even need Swagger if we actually used REST. Swagger is only around because we abandoned REST for RPC.
- zo1 1y ago
  REST is just like scrum/agile. There is apparently some sort of "standard" but really anything goes and everyone does whatever they want.
  - _heimdall 1y ago
    What do you mean? REST was really clearly defined in Roy Fielding's dissertation when he proposed the term in the first place. I agree people do whatever they want and call it REST, but that's not because of a lack of definition in what their term.
hobofan 1y ago
> but by being the same interface for all APIs it reduces the burden on the LLM It doesn't reduce the burden for the LLM, as the LLM isn't the piece of software directly interfacing with the MCP server. It reduced the burden for people building clients that call LLMs and have to convert external interfaces into tool calls etc..

v3ss0n 1y ago

I am looking into ACP and it looks something more solid compared to MCP which is like an intern project. What do you think?

Gerardo1 1y ago

> because MCP brings _nothing_ to the table that I could not do with a "proper" API using completely standard tooling. This is what drives me crazy and has stopped my tinkering with MCP in its tracks: what is the point? It's not bringing anything new. It's usually not easier to set-up than what you're describing. Or, if you absolutely must have an LLM in the mix, normal function calling does just as well as MCP. It's a real, "I feel like I'm taking crazy pills" moment: there's all this hype and bluster and "wow look at this", but there is no "this". Everyone's talking about "it can do" and "it'll be amazing when", but there's nothing actually built and present and ready that is impressive.

zingababba 1y ago
It's not really MCP that is 'this', MCP is just the glue that makes the NLP as frontend easy to conceptualize in terms of application. Everyone is getting excited because it's now relatively obvious how you can go from talking to LLM -> large orchestration happening, even though you could do this already with langchain or whatever. MCP is basically just a protocol you can bring into the context window, do your LLM coding magic, then start up your MCP server and test your tool chain for your NLP as frontend stuff. The only difference is now it's not deterministic so stuff will get randomly fucked up.