Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A critical look at MCP

raz.sh

Post reply on HN
Print view View original

11–20 of 348 posts

Re: A critical look at MCP

#13

Post by hirsin »

In the same way that crypto folks speedran "why we have finance regulations and standards", LLM folks are now speedrunning "how to build software paradigms".

The concept they're trying to accomplish (expose possibly remote functions to a caller in an interrogable manner) has plenty of existing examples in DLLs, gRPC, SOAP, IDL, dCOM, etc, but they don't seem to have learned from any of them, let alone be aware that they exist.

Give it more than a couple months though and I think we'll see it mature some more. We just got their auth patterns to use existing rails and concepts, just have to eat the rest of the camel.

Re: A critical look at MCP

#14

Post by TZubiri »

"Why do I need to implement OAuth2 if I'm using HTTP as transport, while an API key is enough for stdio?"

Because one is made for local and the other for connecting through the internet.

Re: A critical look at MCP

#15

Post by acchow »

hirsin wrote: post #9
justanotheratom wrote: post #3

It is indeed quite baffline why MCP is taking off, but facts are facts. I would love to be enlightened how MCP is better than an OpenAPI Spec of an existing Server.

This is one of the few places I think it's obvious why MCP provides value - an OpenAPI document is static and does no lifting for the LLM, forcing the LLM to handle all of the call construction and correctness on its own. MCP servers reduce LLM load by providing abstractions over concepts, with basically the same benefits we get by not having to write assembly by hand. In a literal sense it's easier, safer, faster, e…

I believe gp is saying the MCP’s “tool/list” endpoint should return dynamic, but OpenAPI-format, content.

Not that the list of tools and their behavior should be static (which would be much less capable)

Re: A critical look at MCP

#17

Post by tedivm »

armdave wrote: post #8
tedivm wrote: post #6

Earlier quoted context omitted.

I'm not saying MCP is perfect, but it's better than OpenAPI for LLMs for a few reasons. * MCP tools can be described simply and without a lot of text. OpenAPI specs are often huge. This is important because the more context you provide an LLM the more expensive it is to run, and the larger model you need to use to be effective. If you provide a lot of tools then using OpenAPI specs could take up way too much for cont…

What does it mean that "different clients can get different specs"? Different in what dimension? I could imagine this makes creating repeatable and reliable workflows problematic.

Using MCP you can send "notifications" to the server, and the server can send back notifications including the availability of new tools.

So this isn't the same as saying "this user agent gets X, this gets Y". It's more like "this client requested access to X set of tools, so we sent back a notification with the list of those additional tools".

This is why I do think websockets make more sense in a lot of ways here, as there's a lot more two way communication here than you'd expect in a typically API. This communication also is very session based, which is another thing that doesn't make sense for most OpenAPI specs which assume a more REST-like stateless setup.

Re: A critical look at MCP

#18

Post by runekaagaard »

justanotheratom wrote: post #3

It is indeed quite baffline why MCP is taking off, but facts are facts. I would love to be enlightened how MCP is better than an OpenAPI Spec of an existing Server.

I thinks a lot is timing and also that it's a pretty low bar to write your first mcp server:

    from mcp.server.fastmcp import FastMCP
    mcp = FastMCP("Basic Math Server")

    @mcp.tool()
    def multiply(a: int, b: int) -> int:
        return a * b

    mcp.run()
If you have a large MCP server with many tools the amount of text sent to the LLM can be significant too. I've found that Claude works great with an OpenAPI spec if you provide it with a way to look up details for individual paths and a custom message that explains the basics. For instance https://github.com/runekaagaard/mcp-redmine

Re: A critical look at MCP

#19

Post by MuffinFlavored »

hirsin wrote: post #13

In the same way that crypto folks speedran "why we have finance regulations and standards", LLM folks are now speedrunning "how to build software paradigms". The concept they're trying to accomplish (expose possibly remote functions to a caller in an interrogable manner) has plenty of existing examples in DLLs, gRPC, SOAP, IDL, dCOM, etc, but they don't seem to have learned from any of them, let alone be aware that t…

Isn't MPC based on JSON-RPC?

Re: A critical look at MCP

#20

Post by hirsin »

MuffinFlavored wrote: post #19
hirsin wrote: post #13

In the same way that crypto folks speedran "why we have finance regulations and standards", LLM folks are now speedrunning "how to build software paradigms". The concept they're trying to accomplish (expose possibly remote functions to a caller in an interrogable manner) has plenty of existing examples in DLLs, gRPC, SOAP, IDL, dCOM, etc, but they don't seem to have learned from any of them, let alone be aware that t…

Isn't MPC based on JSON-RPC?

Indeed! But seemingly only for the actual object representation - it's a start, and I wonder if JSON is uniquely suited to LLMs because it's so text-first.
Post reply on HN