whoknowsidont

>To get this out of the way, you are an unpleasant person

You are clearly very emotional about this, for whatever reason. But again it has no place on this forum.

>I would point out that I haven't see one link in all of your railing against MCP until this very response.

Because everything I've stated are fundamental facts about the technology. If you need sources for it, that means you are missing elementary concepts.

>After meandering

They literally point out several issues with the protocol that hamper observability.

You're being very verbose but not saying much and ignoring when things are directly answered for you. That's being generous.

Your position is like someone claiming lemongrass supplements cures COVID. Everyone is rightly pointing out that it's a placebo at best. Then your position is "well point out all the ways it DOESN'T help, everyone is doing it!"

Which is a really not-smart position to hold, to say the least.

Please give this a read before engaging further: https://huggingface.co/docs/hugs/en/guides/function-calling

You're just utilizing your ignorance to yap at this point.

Probably a good read for you to start with: https://raz.sh/blog/2025-05-02_a_critical_look_at_mcp

There are tons of articles detailing the problems if you are genuinely interested.

Notice you couldn't technically point to anything to support your statements, but instead had to revert to religious zealotry and apologetics -- which has no place on this forum.

>be objective about what MCP is and is not meant to do and disconnect what MCP is from how people are currently using (and frequently misusing) MCP.

Please re-read what you wrote.

You wrote all of that just to counter your own stated position, because I think at some fundamental level you realize how non-sense it is.

You linked to one part of the spec and just wanted to ignore everything else? That's fine, but then you wouldn't be obeying the standard and wouldn't be an "MCP."

So, are you agreeing with me?

Respectfully I think I've engaged with you before and you just seem generally confused about nuanced concepts.

>, they just teach them how to use the tools and then the LLM calls the APIs directly as any HTTP client would.

No. MCP does not do this. Function & tool calling is built into the LLM. MCP is not augmenting this ability in ANY way.

It's not even a standard. It's literally not doing anything here. Not only "can" you rip out MCP there is zero technical reason for any of those things to be an "MCP" in the first place.

Can you do yourself a favor and look at the source code and tell me why you think MCP is necessary here?

I mean you just took some examples and went "See MCP!" without any actual understanding of what that code is doing.

All of these have underlying API's that have exactly ZERO need for MCP. All of this functionality already exists and can be used with LLM's.

* https://help.ableton.com/hc/en-us/articles/209072009-Install...

* https://docs.blender.org/api/current/info_quickstart.html

* https://docs.unity3d.com/6000.2/Documentation/ScriptReferenc...

The most hilarious quote from one of those projects:

>The proxy server is required because the public facing API for UXP Based JavaScript plugin does not allow it to listen on a socket connection (as a server) for the MCP Server to connect to (it can only connect to a socket as a client).

Maybe that should have been the sign that this was completely unnecessary and stupid?

>Do you know of another way you can control all of those applications via LLMs?

Seriously. This becoming a bad joke. I mean conceptually, what did you think was happening here? MCP was just magically doing something that didn't already exist before?

It's a waste of effort and time. Do not use MCP.

>observability

Which MCP does the opposite of. It hides information.

>They have significant data trained on MCP.

No they don't lol.

>It's JSON-RPC, with some descriptors.

That's not even true. It defines the lifecycle of tool calling.

JSON-RPC with some descriptors would have been fine and amazing.

Great! It's still irrelevant.

>is higher as an MCP server than as a CLI command.

What do you mean by "higher"?

Most likely! It's hard to qualify which specific models and version I'm talking about because they're constantly being updated.

But the point is that function & tool calling was already built in. If you take a model from before "MCP" was even referenced on the web it will still _PERFECTLY_ interact with not only other MCP servers and clients but any other API as well.

>dynamically exposes mcp tools as tool calls.

It doesn't even do that. It's not magic.

Training data =/= web search

Both ChatGPT and Claude will perform web searches when you ask them a question, which the fact that you got this confused is ironically topical.

But you're still misunderstanding the principle point because at some point these models will undoubtedly have access to that data and be trained on it.

But they didn't need to be, because LLM function & tool calling is already trained on these models and MCP does not augment this functionality in any way.

>it is "known" at least as much as any other protocol.

No. It is not. Please understand what the LLM's are doing. Claude nor ChatGPT nor any major model knows what MCP is.

They know how to function & tool call. They have zero trained data on MCP.

That is a factual statement, not an opinion.

>This effect is _significantly_ stronger than putting info about available API/cli into CLAUDE.md.

No it's not.

Honestly this conversation is extremely weird to me because somehow people are gravely misunderstanding what MCP even purports to do, let alone what it actually CAN do in the most ideal situation.

It is a protocol and while the merits of that protocol is certainly under active discussion it's irrelevant because you keep adding qualities about the protocol that it cannot deliver on.

Just same facts to help steer this conversation correctly, and maybe help your understanding on what is actually going:

* All LLM's/major models have function & tool calling built in.

* Your LLMs/models do not have any knowledge on MCP, nor have they been trained on it.

* MCP exists, at least the claim, is to help standardize the LIFECYCLE of the tool call.

* MCP does not augment or enhance the ability of LLM's in any form.

* MCP does not allow you to extend agents. That's an implicit feature.

* If you have access to "X" (using your example), you don't need anything that obeys the MCP standard.

MCP at best is for developers and tool developers. Your model does not need an MCP server or client or anything else MCP related to do what is already been trained to do.

>I would personally prefer some other method but having a way to make agents extensible is extremely useful.

They already are. MCP does not help with this.

>but isn't this solved by publishing good API docs, and then pointing the LLM to those docs as a training resource?

Yes.

It's not a dumb question. The situation is so dumb you feel like an idiot for asking the obvious question. But it's the right question to ask.

Also you don't need to "train" the LLM on those resources. All major models have function / tool calling built in. Either create your own readme.txt with extra context or, if it's possible, update the API's with more "descriptive" metadata (aka something like swagger) to help the LLM understand how to use the API.

MCP was a really shitty attempt at building a plugin framework that was vague enough to lure people into and then allow other companies to build plugin platforms to take care of the MCP non-sense.

"What is MCP, what does it bring to the table? Who knows. What does it do? The LLM stuff! Pay us $10 a month thanks!"

LLM's have function / tool calling built into them. No major models have any direct knowledge of MCP.

Not only do you not need MCP, but you should actively avoid using it.

Stick with tried and proven API standards that are actually observable and secure and let your models/agents directly interact with those API endpoints.

>they tend to be as stable as any other cloud provider

Absolutely not.

Another outage brought to you by Azure.

Sounds strangely American.

VRChat has such an amazing, creative community.

>I just honestly can't believe that someone who managed remote teams in 2005 thinks it's the same as managing in 2025

Because it ruins your narrative, not because it's a factual observation lol. The software your entire life is based on was built using remote teams.

>As the other commenter stated

Surely if you're able to read their comment you're able to read my response. All of these points were addressed and voided.

Go on wikipedia and read about the era or something, instead of larping as someone who was actually there.

>static for decades I was chastised for not giving specific examples.

Any examples, really.

>The level of cluelessness on display here is just baffling to me.

I encourage you to give this thread an honest, deep think about why you feel this way. It's certainly not lack of insight from the other side. The word accountability is relevant here.

>Gigabit internet - video call quality is significantly better than it was 10-15 years ago.

You don't need gigabit internet for good video quality. We solved this with the MPEG-4, specifically H.264.

Most video streaming software still uses H.264 to this day, or some "mimic" of it. This was 15+ years ago btw.

You only need like, maybe 100 Mbps. Most definitely less for normal conferences.

> Zoom/Google Meets - the attention Zoom gave to UX just wasn't matched by any other precursor. Google Meets is a close second.

Opinion based, and you're welcome to have it. But not sure what qualifies as any sort of good evidence or reason for companies moving to other countries for their labor force.

>GSuite/O365 - sharing documents across organizations and being able to search for them successfully org wide has gotten much better now due to tools like Glean

Again, you're welcome to your opinions. Sharing documents in organizations across cities, states, and countries has been pretty mainstay for 30+ years.

And if you want my honest opinion, the tooling has gotten worse.

> Slack - most traditional companies didn't adopt Slack until the pandemic. Before that they were primarily leveraging email

At this point I'm just having trouble understanding why you think these things are fundamentally game changers.

>and DevTooling throughout the 2010s

Like what?

Again, if that's the best examples you could come up with they're not really enough and even worse (in the cases of GSuite/365) they are counter to your point about tooling improvement.

Detail what changed? Because I can't point to anything. And I've been doing this for 4+ decades. A lot of that remote.

So you're claiming things radically changed, and if such changes caused a huge shift in the workforce it should be pretty easy to give some examples, yeah?

Instead of going "you're full of shit", just answer the question at hand and the one that was given to you multiple times.

The fact that it's so easy to do and you just spent way more effort not doing it is a pretty clear indication you are following a narrative, and not facts.

>Is it really hard to understand that the infrastructure for remote work, which I think everyone would agree got a major upgrade during the pandemic, would also make it much easier for companies to outsource software dev work?

No, because it wasn't actually upgraded.

Like be honest, the shift into remote work wasn't surrounded by massive tech advances or upgrades. All the tools that existed for remote work had been there, largely in the same fashion and capability, for decades.

So when you say the infra. and tooling has improved, you need to be specific because it's very hard to point to anything that was fundamentally or notably improved in the pandemic around remote work.

It all existed before. It was all used before. If you weren't using it before the pandemic that was by choice, not because it didn't exist.

Everything from our communication software, to developer collaboration tools, to how org's track and manage their employees all existed well, well before the pandemic.

It was a cultural change -- not a technological one.

> And that is a change that only happened around the beginning of the pandemic

I'm not sure what you're basing this on. Especially someone's that's had to work with peers across the globe for 4+ decades -- the tools have always been there.

>But rather that workplaces and workforces geared towards remote working has made it more feasible and accelerated the process

By what metrics?

Not sure where the gap would be, it's pretty straight forward.