Comment by jjfoooo4
16 hours 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
16 hours 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
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.
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.
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.
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.
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.
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.
8 replies →
> 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.
> 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.
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).
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)
3 replies →
How do I integrate tool calling in an IDE (such as Zed) without MCP?
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
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.
There’s nothing special about llm tools. They’re really just script invocations. A command runner like just does everything you need, and makes the tools available to humans.
I wrote a bit on the topic here: https://tombedor.dev/make-it-easy-for-humans/
Dynamic code generation for calling APIs, not sure what is a fancy term for this approach.
Something like https://github.com/huggingface/smolagents
Needs a sandbox, otherwise blindly executing generated code is not acceptable
https://www.anthropic.com/engineering/advanced-tool-use#:~:t...
Anthropic themselves support this style of tool calling with code first party now too.
1 reply →
Cloudflare published this article which I guess can be relevant https://blog.cloudflare.com/code-mode/
this assumes generated code is always correct and does exactly what's needed.
4 replies →
You don't need to replace it. Just please stop using it.
If for nothing else than pure human empathy.
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.
But like, it's just openAPI with an endpoint for getting the schema, like how is that more universal than openAPI?
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.