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

291–300 of 348 posts

Re: A critical look at MCP

#291

Post by ethbr1 »

brabel wrote: post #251
FridgeSeal wrote: post #209

Earlier quoted context omitted.

Hey there, expecting basically literacy or comprehension out of a sub-industry seemingly dedicated to minimising human understanding and involvement is bridge too far. Clearly if these things are problems, AI will simply solve them, duhhh. /s

You joke, but with the right prompt, I am almost certain that an LLM would've written a better spec than MCP. Like others said, there are many protocols that can be used as inspiration for what MCP tries to achieve, so LLMs should "know" how it should be done... which is definitely NOT by using SSE and a freaking separate "write" endpoint.

> with the right prompt

That's LLM in a nutshell though. A naive prompt + taking the first output = high probability of garbage. A thoughtful prompt informed by subject matter expertise + evaluating, considering, and iterating on output = better than human-alone.

But the pre-knowledge and creative curation are key components of reliable utility.

Re: A critical look at MCP

#292

Post by lolinder »

reliabilityguy wrote: post #290
lolinder wrote: post #219

Earlier quoted context omitted.

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.

No real human being would misunderstand because, as you note, time can't go slower. This is just an excuse for pedantry.

Re: A critical look at MCP

#293

Post by lolinder »

brabel wrote: post #249
lolinder wrote: post #219

Earlier quoted context omitted.

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/…

This sentence is a good example where the native speaker's version is worse (in this case because it's just non-sense, as the parent commenter already pointed out).

Sounds like you're the kind of person who will insist to Spanish speakers that a double negative is logically incoherent. Good luck with that approach to language!

Re: A critical look at MCP

#294

Post by NicuCalcea »

bsenftner wrote: post #270

I'll say it: MPC is immature trash, and will be replaced with... nothing. It is not needed, nor necessary if one has any functional engineering experience. It's yet another poorly considered distraction created by the software industry that cannot tie it's own shoes.

> It is not needed, nor necessary if one has any functional engineering experience

There indeed are people without functional engineering experience. I wrote some software meant to be used by journalists. MCP is a great fit for it, it allows the tool to be expanded and adapted to their needs without having to code the whole thing themselves.

Re: A critical look at MCP

#295

Post by lolinder »

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…

Yes, this is a good explanation for the phenomenon! Thanks.

Re: A critical look at MCP

#296

Post by lolinder »

reliabilityguy wrote: post #289
fnord123 wrote: post #273

Earlier quoted context omitted.

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.

Exactly.

"Response times will be higher" sounds very confusing as a way of saying we'll take less time to respond, right? So why should "response times will be lower" mean we'll take more time if the opposite construct is confusing?

Far better to just use the comparative forms that we already have for time specifically to make it perfectly clear.

Re: A critical look at MCP

#297

Post by maCDzP »

The comments are mostly negative, so I’ll add my experience as a non coder.

I wanted to let Claude search an open data source. It’s my counties version of library of congress.

So I pointed Claude to the MCP docs and the API spec for the open data. 5 minutes later I had a working MCP client so I can connect Claude to my data set.

Building that would have taken me days, now I can just start searching for the data that I want.

Sure, I have to proof read everything that the LLM turn out. It I believe that’s better than reading and searching though the library.

Re: A critical look at MCP

#298

Post by lolinder »

maCDzP wrote: post #297

The comments are mostly negative, so I’ll add my experience as a non coder. I wanted to let Claude search an open data source. It’s my counties version of library of congress. So I pointed Claude to the MCP docs and the API spec for the open data. 5 minutes later I had a working MCP client so I can connect Claude to my data set. Building that would have taken me days, now I can just start searching for the data that…

I don't think any of the negativity is about whether MCP works. It's just about whether MCP is a horribly ill-planned design that could have been much better if they'd taken the time to learn from the 50 years of experience we have as an industry in building protocols.

That it works is in some ways worse because it means we'll be stuck with it. If it didn't work we'd be more likely to be able to throw it away and start over.

Re: A critical look at MCP

#300

Post by DanHulton »

This is honestly kind of hilarious. I fell briefly in love with SSE last summer and started to write a chat/game web server using them, only to step on every rake the author describes and attempt nearly every band-aid solution the MCP protocol implements, only to throw my hands up at the end, disgusted with the mess I made, and embrace WebSockets instead. After about a day's refactor, I had about three-quarters less code that was _much_ easier to reason about, and didn't have several key limitations I was uneasy about in my SSE implementation.
Post reply on HN