[felixrieseberg]

Disclosure: I work at Anthropic, have worked on MCP

I also think this is pretty big. I think a problem we collectively have right now is that getting MCP closer to real user flows is pretty hard and requires a lot of handholding. Ideally, most users of MCP wouldn't even know that MCP is a thing - the same way your average user of the web has no idea about DNS/HTTP/WebSockets. They just know that the browser helps them look at puppy pictures, connect with friends, or get some work done.

I think this is a meaningful step in the direction of getting more people who'll never know or care about MCP to get value out of MCP.

[CuriouslyC]

I want to try and understand what you guys see as the win from MCP. It's objectively inferior to code/clis across a ton of dimensions. The main value I see from it is as a single point to "sandbox" what your agents can do, but it seems a little awkward for that use case.

[c-hendricks]

LLMs are used outside of programming though. It's much easier to hook up a HTTP MCP than it is to install and update a CLI on the execs machines.

[bradgessler]

I built https://terminalwire.com around the idea that CLIs are a great way to interact with web applications.

Turns out the approach works well for integrating web apps with LLMs. I have a payroll company using it in their stack to replace MCP and they’re reporting lower token usage and a better end result.

[sixtyj]

Re CLI: In fact it seems to be very similar to command line in AutoCAD (you can do things visually with mouse or choose to draw via CLI). With LLMs it is more sophisticated (intelligent) because you are not limited with set of predefined commands.

I am waiting for Excel CLI…

[somnium_sn]

I want to also highlight that this is an optional "extension" to MCP, not a required part of specification. If you are a terminal application, only care about tool calling, etc, you are free to skip this. If you want to enable rich clients, then it might be something to consider implementing.

[pylotlight]

Can you potentially review utcp.io for seeing what MCP should have been to avoid context overloading? The dynamic tool search option and codemode to avoid loading all tools/servers into context seems like a better method imo.

[iLoveOncall]

I wonder how long it'll take you to figure out that you're trying to reinvent deterministic APIs.

[troupo]

Or just APIs in general.

MCP is incredibly vibe-coded. We know how to make APIs. We know how to make two-way communications. And yet "let's invent new terminology that makes little sense and awkward workarounds on top of unidirectional protocols and call it the best thing since sliced cheese".

[james_marks]

MCP is not just providing an API, it’s providing a client that uses that API.

And it does so in a standard way so that my client is available across AI providers. My users can install my client from an ordained URL without getting phished, or the LLM asking them to enter an API key.

What’s the alternative? Providing a sandbox to execute arbitrary code and make API calls? Having an LLM implement OAuth on the fly when it needs to make an API call?

MCP has a place.

[troupo]

> MCP is not just providing an API

It does just provide an API. Your client may have a way to talk to some software via MCP protocol. You know, like a client can talk to a server exposing an endpoint via an API.

> And it does so in a standard way so that my client is available across AI providers.

As in: it's an API on a port with a schema that a certain subset of software understands.

> What’s the alternative? Providing a sandbox to execute arbitrary code and make API calls?

MCP is a protocol. It couldn't care less what you do with your "tool" calls. Vast majority of clients and servers don't run in any sandbox at all. Because MCP is a protocol, not a docker container.

> Having an LLM implement OAuth on the fly when it needs to make an API call?

Yes, MCP has also a bolted-on authorisation that they didn't even think of when they vibe-coded the protocol. And at least finally there was some adult in the room that said "perhaps you should actually use a standardised way to do this". You know, like all other APIs get OAuth (and other types) of authorisations.

[james_marks]

Perhaps confusingly, I’m referring to MCP as the sum of the protocol, a server adhering to the protocol, and clients adding support (e.g. “Connectors”).

The combination of these things turns into an ecosystem.

[mcpeepants]

MCP is a Protocol. The server and the clients are just that. It truly is a rebranding of “API” seemingly just because it’s for a specific purpose. Not that there’s anything wrong with that… call it whatever. But I don’t understand the need to sell it as something else entirely. It is quite literally a reinvention of RPC.

[troupo]

> I’m referring to MCP as the sum of the protocol, a server adhering to the protocol, and clients adding support (e.g. “Connectors”).

Why?

Do you refer to REST APIs or GraphQL as a whole? There are servers "adhering to the protocol" and "clients adding support" for these.

These are literally APIs.

[stingraycharles]

What is indeterministic about MCP servers? Most of them follow fairly simple rules, eg an MCP server to interact with Slack gives pretty deterministic responses to requests.

Or are you confusing the LLM / MCP client invoking the tools being non-deterministic?

[neoden]

MCP is already deterministic. What's huge about it is that it has automatic API discovery and integration built-in. It's a bit rough yet but I think we will only see how it's getting improved more and more.

[degamad]

> automatic API discovery and integration

So, WSDL?

[brazukadev]

Yes, WSDL is great for it, now go ahead and convince people. What is your marketing budget?

[0x696C6961]

You really want to use WSDL? OpenAPI v3 would be a much better fit. But it has a tone of features that are completely unnecessary for this use-case. What if we just stripped it down to input and output json schemas? Oh wait ... we just invented MCP.

[EagnaIonat]

WSDL just told you what API was there and create the interface for you in code.

It actually never tried to figure out what API call you actually needed based on what the user asked and how to handle it in real time.

I mean it could, but WSDL was already superseded by REST.

[neoden]

no, thank you