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

331–340 of 348 posts

Re: A critical look at MCP

#331

Post by fnord123 »

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.

It makes more sense if the direction is split from the unit in the sentence.

Consider: "after investigating response times and doing and doing a bunch of work, my PR causes a 30% reduction" - if you're busy doing lots of things and already have a lot of cognitive load, this could sound bad because the important phrase "30% reduction" is in there. You are a detail oriented person who is immune to this effect, but there are people who need help reducing their cognitive load in this type of thing.

You can help people reduce cognitive load by replacing "reduction" with "improvement" so they immediately understand that it moved in the right direction.

Re: A critical look at MCP

#332

Post by numpad0 »

ComplexSystems wrote: post #329
numpad0 wrote: post #327

Earlier quoted context omitted.

Why do we not pretend like foreign language technical ghostwriting is a solved problem! You guys are asking for complete rewrites by someone explicitly NOT Chinese natives for all documentations. There's some point it'll be just an unreasonable ask. A lot of HNers puts blind trust on Universal Grammar Theory and downplay languages as all but obsolete human output packing format that are each no more than header diffe…

I think this would have been a great argument to make 5 years ago. Now, it's absurd. DeepSeek itself can clean this up and output perfect English.

Nope, I've tried it in one of other comments, it didn't go so well. It's minimum 5 years away from being one prompt away. GPT-2 was 6 years ago and we still don't have self driving cars(except Waymo which always worked), so it could even be longer.

Re: A critical look at MCP

#333

Post by ComplexSystems »

numpad0 wrote: post #332
ComplexSystems wrote: post #329

Earlier quoted context omitted.

I think this would have been a great argument to make 5 years ago. Now, it's absurd. DeepSeek itself can clean this up and output perfect English.

Nope, I've tried it in one of other comments, it didn't go so well. It's minimum 5 years away from being one prompt away. GPT-2 was 6 years ago and we still don't have self driving cars(except Waymo which always worked), so it could even be longer.

Here's a refined version of your text:

---

*DeepSeek API Rate Limit & Service Notice* DeepSeek imposes no rate limits on users, and we strive to fulfill all requests.

During periods of high server traffic, responses may be delayed. While waiting, your HTTP connection will remain active, and you may continue to receive content in the following formats:

[Insert specific formats here]

---

*Key improvements:* 1. Corrected "try out best" → "strive" for conciseness and professionalism. 2. Simplified "under high traffic pressure" → "high server traffic." 3. Streamlined phrasing (e.g., "remain connected" → "remain active"). 4. Structured the message for clarity and readability.

Let me know if you'd like further adjustments!

Re: A critical look at MCP

#334

Post by efitz »

This article really hit home for me. I am trying to integrate an MCP interface into a server application only to realize that Anthropic didn't seem to have considered server side use cases at all; to them everything looks like an electron app. Then they added JSON-RPC support as an afterthought with only browser-like transports. It is either arrogance or ignorance to fail to exclude something basic like a RESTful API or gRPC or even just websockets.

Re: A critical look at MCP

#335

Post by int_19h »

aerhardt wrote: post #320
Timwi wrote: post #207

Earlier quoted context omitted.

Static functions (len, map/filter,...) that should have been methods on objects.

What’s the root cause? It certainly makes functional semantics in Python suck. Comprehensions don’t make up for it.

How so, given that those are also free-standing functions in most languages that are considered purely or mostly functional? (e.g. ML, Haskell)

Re: A critical look at MCP

#336

Post by int_19h »

Timwi wrote: post #207
volemo wrote: post #131

Earlier quoted context omitted.

Could you throw on a couple of examples of calcified early mistakes of Python? GIL is/was one, I presume?

Static functions (len, map/filter,...) that should have been methods on objects.

map() and filter() work on any iterable, so it's not clear which type you'd expect them to be methods on (keeping in mind that the notion of "iterable" in Python is expressed through duck typing, so there's no interface like say .NET IEnumerable where they would naturally belong).

len() guarantees that what you get back is an integer. If some broken type implements __len__() poorly by returning something else, len() will throw TypeError. You can argue that this is out of place for Python given it overall loose duck typing behavior, but it can still be convenient to rely on certain fundamental functions always behaving well. Similar reasoning goes for str(), repr(), type() and some others.

One can reasonably argue that Python should have something similar to C# extension methods - i.e. a way to define a function that can be called like a method, but which doesn't actually belong to any particular type - and then all those things would be such functions. But, given the facilities that Python does have, the design of those functions makes sense.

Re: A critical look at MCP

#337

Post by __loam »

jtms wrote: post #325
__loam wrote: post #86

Earlier quoted context omitted.

The Langchain repo is actually hilariously bad if you ever go read the source. I can't believe they raised money with that crap. Right place right time I guess.

Yeah agree. I spent a few hours looking at the langchain repo when it first hit the scene and could not for the life of me understand what value it actually provided. It (at least at the time) was just a series of wrappers and a few poorly thought through data structures. I could find almost no actual business logic.

It provides negative value by marrying your project to a bunch of unnecessary oop bullshit lol

Re: A critical look at MCP

#338

Post by ericksoa »

vmaurin wrote: post #57

It will probably never work. Companies have spend probably the last decade(s?) closing everything on Internet: * no more RSS feed * paywall * the need to have an "app" to access a service * killing open protocols And all of the sudden, everyone will expose their data through simple API calls ?

You either do it, or someone wraps you with one using browser_use or similar.

Re: A critical look at MCP

#339

Post by toonalfrink »

rco8786 wrote: post #288
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 t…

In other words, MCP is RESTful (as in, it has HATEOAS) and "REST" is not

Re: A critical look at MCP

#340

Post by airspresso »

cmrdporcupine wrote: post #284
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.

Yes the authors openly acknowledge [0] to be inspired by LSP.

[0]: https://www.latent.space/p/mcp

Post reply on HN