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

281–290 of 348 posts

Re: A critical look at MCP

#281

Post by mrcsharp »

nitely wrote: post #248
mrcsharp wrote: post #226

Earlier quoted context omitted.

Well with SSE the server and client are both holding a HTTP connection open for over a relatively long period of time. If the server is written with a language that supports async paradigms, then a http request that needs async IO will use about the same amount of resource anyways. And when the response if finished, that connection is closed and resources are freed. Whereas SSE will keep them for much longer.

Yes, and the client may do multiple requests, and if all take long to be processed you may end up with a lot of open connections at the same time (at least on http1), so there is a point to fast HTTP requests+SSE, instead of slow requests (and no SSE). Granted, if the server is HTTP2 the requests can share the same connection, but then it'd be similar to just using WS for this usage. Also, this allows to queue the wo…

You make a good point about queuing up the work. You do get more control over resource management in this case.

Re: A critical look at MCP

#282

Post by yard2010 »

ComplexSystems wrote: post #227
fakedang wrote: post #220

Earlier quoted context omitted.

I've seen documents that were applications by CCP-affiliated provincial government bodies, things like detailed studies for loan applications to international banks, etc. and trust me, the Deepseek documentation is miles ahead of that. These are official government documents from one government agency to some international agency.

This has fascinated me for years. I'll just re-link this comment of mine from a few years ago: https://news.ycombinator.com/item?id=37544019#37548278 . This was about Amazon products rather than government documentation, but the point is the same. I'll just quote the relevant part: > The people who make these products have to spend millions and millions of dollars setting up factories, hiring people, putting things i…

One of my guilty pleasures is to read random chinese product pages and try not to laugh.

Re: A critical look at MCP

#283

Post by koakuma-chan »

fullstackchris wrote: post #269
koakuma-chan wrote: post #144

Earlier quoted context omitted.

> As in, how MCP client can access `git` command without stdio? MCP clients don't access any commands. MCP clients access tools that MCP servers expose.

Here's a custom MCP tool I use to run commands and parse stdout / stderr all the time: try { const execPromise = promisify(exec); const { stdout, stderr } = await execPromise(command); if (stderr) { return { content: [{ type: "text", text: `Error: ${stderr}` }], isError: true }; } return { content: [{ type: "text", text: stdout }], isError: false }; } catch (error: any) { return { content: [{ type: "text", text: `Err…

The point is that MCP servers expose tools that can do whatever MCP servers want them to do, and it doesn’t have to have anything to do with stdio.

Re: A critical look at MCP

#284

Post by cmrdporcupine »

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…

It reminds me a bit of LSP, which feels to me like a similar speed-run and a pile of assumptions baked in which were more parochial aspects of the original application... now shipped as a standard.

And yeah, sounds like it's explicitly a choice to follow that model.

Re: A critical look at MCP

#285

Post by angusturner »

I think this is article is too generous about the use of stdio - I have found this extremely buggy so far, especially in the python sdk.

Also if you want to wrap any existing code that logs or prints to stdout then it causes heaps of ugly messages and warnings as it interferes with the comms between client and server.

I just want a way to integrate tools with Claude Desktop that doesn’t make a tonne of convoluted and weird design choices.

Re: A critical look at MCP

#286

Post by angusturner »

keithwhor wrote: post #90

On MCP's Streamable HTTP launch I posted a issue asking if we should just simplify everything for remote MCP servers to just be HTTP requests. https://github.com/modelcontextprotocol/modelcontextprotocol... MCP as a spec is really promising; a universal way to connect LLMs to tools. But in practice you hit a lot of edge cases really quickly. To name a few; auth, streaming of tool responses, custom instructions per to…

I’m really glad to see people converging on this view because I feel a bit insane for not understanding all the hype.

Like, yeah, we need a standard way to connect LLMs with tools etc, but MCP in its current state is not a solution.

Re: A critical look at MCP

#287

Post by LegNeato »

foobarian wrote: post #24
_raz wrote: post #22

Earlier quoted context omitted.

Yes, the protocol seems fine to me in and of itself. It's the transport portion that seems to be a dumpster fire on the HTTP side of things.

Must have used GraphQL as a role model no doubt

GraphQL is transport agnostic

Re: A critical look at MCP

#288

Post by rco8786 »

keithwhor wrote: post #90

On MCP's Streamable HTTP launch I posted a issue asking if we should just simplify everything for remote MCP servers to just be HTTP requests. https://github.com/modelcontextprotocol/modelcontextprotocol... MCP as a spec is really promising; a universal way to connect LLMs to tools. But in practice you hit a lot of edge cases really quickly. To name a few; auth, streaming of tool responses, custom instructions per to…

> It's still not entirely clear (for remote servers) to me what you can do with MCP that you can't do with just a REST API,

Nothing, as far as I can tell.

> the latter being a much more straightforward integration path.

The (very) important difference is that the MCP protocol has built in method discovery. You don't have to 'teach' your LLM about what REST endpoints are available and what they do. It's built into the protocol. You write code, then the LLM automatically knows what it does and how to work with it, because you followed the MCP protocol. It's quite powerful in that regard.

But otherwise, yea it's not anything particularly special. In the same way that all of the API design formats prior to REST could do everything a REST API can do.

Re: A critical look at MCP

#289

Post by reliabilityguy »

fnord123 wrote: post #273
reliabilityguy wrote: post #216

Earlier quoted context omitted.

> "Our response times may be slower" would be more natural. How can the time be slower? Response times may be longer, but not slower

When you remark on improvements, up is generally better and down is generally worse. So saying "response times will be higher" gives an immediate sentiment of improvement. But, obviously, a moments thinking helps you re-orient and realize it's better. This is why plots often have "lower is better" in the legend, to help readers understand. I often use 'slower' and 'faster' as a native speaker to help reinforce the me…

> "response times will be higher" gives an immediate sentiment of improvement.

Higher as opposed to lower? It makes no sense to me.

Re: A critical look at MCP

#290

Post by reliabilityguy »

lolinder wrote: post #219
reliabilityguy wrote: post #216

Earlier quoted context omitted.

> "Our response times may be slower" would be more natural. How can the time be slower? Response times may be longer, but not slower

In colloquial English my construction is just fine, but sure, you'd be welcome to pick longer too. Some examples of my usage in the wild ("response times may be slower" is present verbatim on each page): https://github.com/aquasecurity/trivy/discussions/8133 https://www.ameristarstaffingny.com/the-negative-effects-of-... https://oci.wi.gov/Pages/Regulation/Bulletin20200320Regulato... https://playrix.helpshift.com/hc/…

> In colloquial English my construction is just fine,

Maybe. However, in my opinion, it’s better to write in such a way that leaves zero chance for misunderstanding.

Post reply on HN