Comment by jjfoooo4

2 months ago

It really feels to me that MCP is a fad. Tool calling seems like the overwhelming use case, but a dedicated protocol that goes through arbitrary runtimes is massive overkill

64 comments

jjfoooo4

Reply
mooreds  2 months ago

I've been involved with a few MCP servers. MCP seems like an API designed specifically for LLMs/AIs to interact with.

Agree that tool calling is the primary use case.

Because of context window limits, a 1:1 mapping of REST API endpoint to MCP tool endpoint is usually the wrong approach. Even though LLMs/agents are very good at figuring out the right API call to make.

So you can build on top of APIs or other business logic to present a higher level workflow.

But many of the same concerns apply to MCP servers as they did to REST APIs, which is why we're seeing an explosion of gateways and other management software for MCP servers.

I don't think it is a fad, as it is gaining traction and I don't see what replaces it for a very real use case: tool calling by agents/LLMs.

  • beepbooptheory  2 months ago

    > MCP seems like an API designed specifically for LLMs/AIs to interact with

    I guess I'm confused now, I thought that what it explicitly is.

giamma  2 months ago

I am more interested in how MCP can change human interaction with software.

Practical example: there exists an MCP server for Jira. Connect that MCP server to e.g. Claude and then you can write prompts like this:

"Produce a release notes document for project XYZ based on the Epics associated to version 1.2.3"

or

"Export to CSV all tickets with worklog related to project XYZ and version 1.2.3. Make sure the CSV includes these columns ....."

Especially the second example totally removes the need for the CSV export functionality in Jira. Now imagine a scenario in which your favourite AI is connected via MCP to different services. You can mix and match information from all of them.

Alibaba for example is making MCP servers for all of its user-facing services (alibaba mail, cloud drive, etc etc)

A chat UI powered by the appropriate MCP servers can provide a lot of value to regular end users and make it possible for people to use their own data easily in ways that earlier would require dedicated software solutions (exports, reports). People could use software for use cases that the original authors didn't even imagine.

  • yard2010  2 months ago

    I bet it would work the same with REST API and any kind of specs, be it OpenAPI or even text files. From my humble experience.

    • theshrike79  2 months ago

      It would, but the point of MCP is that it's discoverable by an AI. You can just go change it and it'll know how to use it immediately

      If you go and change the parameters of a REST API, you need to modify every client that connects to it or they'll just plain not work. (Or you'll have a mess of legacy endpoints in your API)

      Not a fan, I like the "give an LLM a virtual environment and let it code stuff" approach, but MCP is here to stay as far as I can see.

      2 replies →

bastardoperator  2 months ago

I'm kind of in the same boat, I'm probably missing something big, this seems like a lot of work to serve a json file with a url.

rtp4me  2 months ago

I have been creating an MCP server over the past week or so. Based on what I have seen first hand, an MCP can give much richer context to the AI engine just by using very verbose descriptions in the functions. When it the AI tool (Claude Desktop, Gemini, etc) connects to the server, it examines the descriptions in each function and gets much better context on how to use the tool. I don't know if an API can do the same. I have been very, very impressed how much Claude can do with a good MCP.

dist-epoch  2 months ago

MCP is a universal API - a lot of web services are implementing it, this is the value it brings.

Now there are CLI tools which can invoke MCP endpoints, since agents in general fare better with CLI tools.

  • hahn-kev  2 months ago

    But like, it's just openAPI with an endpoint for getting the schema, like how is that more universal than openAPI?

    • hobofan  2 months ago

      Most of the value lies in its differentiation to OpenAPI and the conventions it brings.

      By providing an MCP endpoint you signify "we made the API self-describing enough to be usable by AI agents". Most existing OpenAPI specs out there don't clear that bar, as endpoint/parameter descriptions are underdocumented and are unusable without supplementary documentation that is external to the OpenAPI spec.

      4 replies →

DANmode  2 months ago

What sort of structure would you propose to replace it?

What bodies or demographics could be influential enough to carry your proposal to standardization?

Not busting your balls - this is what it takes.

  • jascha_eng  2 months ago

    Why replace it at all? Just remove it. I use AI every day and don't use MCP. I've built LLM powered tools that are used daily and don't use MCP. What is the point of this thing in the first place?

    It's just a complex abstraction over a fundamentally trivial concept. The only issue it solves is if you want to bring your own tools to an existing chatbot. But I've not had that problem yet.

    • anon84873628  2 months ago

      Ah, so the "I haven't needed it so it must be useless" argument.

      There is huge value in having vendors standardize and simplifying their APIs instead of having agent users fix each one individually.

      17 replies →

    • maxwellg  2 months ago

      > The only issue it solves is if you want to bring your own tools to an existing chatbot.

      That's a phenomenally important problem to solve for Anthropic, OpenAI, Google, and anyone else who wants to build generalized chatbots or assistants for mass consumer adoption. As well as any existing company or brand that owns data assets and wants to participate as an MCP Server. It's a chatbot app store standard. That's a huge market.

    • UncleEntity  2 months ago

      Isn't that the way if works, everybody throws their ideas against the wall and sees what sticks? I haven't really seen anyone recommend using xml in a long while...

      And isn't this a 'remote' tool protocol? I mean, I've been plugging away at a VM with Claude for a bit and as soon as the repl worked it started using that to debug issues instead of "spray and pray debugging" or, my personal favorite, make the failing tests match the buggy code instead of fixing the code and keeping the correct tests.

    • thomasfromcdnjs  2 months ago

      I have Linear(mcp) connected to ChatGPT and my Claude Desktop, and I use it daily from both.

      For the MCP nay sayers, if I want to connect things like Linear or any service out there to third party agentic platforms (chatgpt, claude desktop), what exactly are you counter proposing?

      (I also hate MCP but gets a bit tiresome seeing these conversations without anyone addressing the use case above which is 99% of the use case, consumers)

      4 replies →

    • p_ing  2 months ago

      > What is the point of this thing in the first place?

      It's easier for end users to wire up than to try to wire up individual APIs.

    • tunesmith  2 months ago

      So, I've been playing with an mcp server of my own... the api the mcp talks to is something that can create/edit/delete argument structures, like argument graphs - premises, lemmas, and conclusions. The server has a good syntactical understanding of arguments, how to structure syllogisms etc.

      But it doesn't have a semantic understanding because it's not an llm.

      So connecting an llm with my api via MCP means that I can do things like "can you semantically analyze the argument?" and "can you create any counterpoints you think make sense?" and "I don't think premise P12 is essential for lemma L23, can you remove it?" And it will, and I can watch it on my frontend to see how the argument evolves.

      So in that sense - combining semantic understanding with tool use to do something that neither can do alone - I find it very valuable. However, if your point is that something other than MCP can do the same thing, I could probably accept that too (especially if you suggested what that could be :) ). I've considered just having my backend use an api key to call models but it's sort of a different pattern that would require me to write a whole lot more code (and pay more money).

    • tonmoy  2 months ago

      The less context switching LLMs of current day need to do the better they seem to perform. If I’m writing C code using an agent but my spec needs complex SQL to be retried then it’s better to give access to the spec database through MCP to prevent the LLM from going haywire

  • ekropotin  2 months ago

    Dynamic code generation for calling APIs, not sure what is a fancy term for this approach.