←back to thread

MCP is eating the world

(www.stainless.com)
335 points emschwartz | 1 comments | | HN request time: 0.287s | source
Show context
time0ut ◴[] No.44367747[source]
In some ways MCP is like the next evolution of API over HTTP.

We've exposed our APIs as SOAP endpoints. These were not well suited to web based clients, leading to the development of "RESTful" JSON endpoints. As web clients became more complex, GraphQL arose as a solution to some of the problems encountered. Maybe MCP is the next step.

I don't mean that MCP will supersede these protocols. My company exposes our endpoints as SOAP, REST, and GraphQL still as they fit different use cases and customer bases. We are piloting an MCP version to see how that goes now.

It is fun to work on something new and play with agents to see how they consume our endpoints in this form. I think there is a lot of potential.

replies(1): >>44367935 #
v3ss0n ◴[] No.44367935[source]
Unecessary complication. LLM Can call tools without MCP 100% fine. You don't need a Stateful SSE JSORPC Meshedup server running APIs rebraneded as tools at somewhere on the cloud .
replies(2): >>44368062 #>>44368312 #
jcelerier ◴[] No.44368312[source]
> LLM Can call tools without MCP 100% fine.

but can the LLM host UI ask me for permission (in an outside-of-LLM domain) if the LLM wants to call API foo.bar ?

replies(2): >>44368773 #>>44368886 #
v3ss0n ◴[] No.44368886[source]
Thats all part of how you code the LLMHost Backend and Frontend. I build several MCP and MCP-Less tool calling agents using autogen and they can ask the user permission. That is nothing to do with MCP at all.

Look into AutoGen by microsoft or if you want more basic , learn how tool calling in LLMs work.

replies(2): >>44378058 #>>44379928 #
1. jcelerier ◴[] No.44379928[source]
> Thats all part of how you code

I mean I certainly don't want to code my own LLM UI