Live data from Hacker News

A critical look at MCP

raz.sh

321–330 of 348 posts

Re: A critical look at MCP

#321

Earlier quoted context omitted.

What’s the problem? Can you point out a specific thing you would change from that quote?

Are you a native English speaker? "does NOT constrain user's rate limit" should be "does NOT rate limit incoming requests" or similar. "We will try out best" should be "our best". "when our servers are under high traffic pressure" is at least grammatical, but it's awkward. Normally you'd say "when our servers are dealing with high load" or something similar. "your requests may take some time to receive a response fro…

If your problem is that the texts you quoted were not written by someone with English as the first language, I tell you: English is not the framework of human civilization, it sometimes uses English for data quantization and message passing.

A lot of English native speakers has such assumptions that:

- any academic topics are universally discussed in English/Latin and so every highly educated person shall speak good English, - language is like a thin wrapper over a to-be-converted-to-YAML common intermediate language(Universal Grammar theory), - anything should translate into fluid English with intent completely intact, - but WWW is >90% English anyway, - etc.

None of these are true, and it's just not realistic for a well educated East Asian - common theme of East Asian languages is it's all custom implementations with minimal sharing with neighbors let alone English - to "just" pick up natural English. I suppose you're looking for something like following:

"At DeepSeek, we strive to serve every request to our customers with best of our effort, and we do not impose a rate limit for our APIs. However, do note that due to finite nature of our computing resources, API responses might become delayed in cases when our backend is experiencing high load. Under such circumstances, the HTTP sessions will be kept alive, and response will be served in following formats..."

... Isn't this a $1m/yr skill on its own? Have you seen a great Far East engineer write like this - I mean, how often do you come across a Far Eastern translator that can casually do this?

Re: A critical look at MCP

#322

Earlier quoted context omitted.

I mean, it's not so easy getting a perfectly knowledgeable English speaker in China. Heck, if you see some of the interviews of the insanely viral Tony from LC Signs, his English outside of his skits is actually very Chinese-flavored. One of my friend's exes who was Chinese and studied at Oxbridge had a very similar strong Chinese twang, and often made grammatical mistakes while writing, even though the British would…

DeepSeek is a perfectly knowledgeable English speaker in China.

  [me]
  > Translate to palatable startup-style English:
  >> DeepSeek API 不限制用户的访问速率。我们会尽力满足每个请求。但是,请注意,当我们的服务器流量压力较大时,您的请求可能需要一些时间才能收到服务器的响应。在此期间,您的 HTTP 请求将保持连接状态,您可能会持续收到以下格式的内容……

  [LLM]
  > Here's a more palatable, startup-style translation of your message:
  > DeepSeek API has no hard rate limits. We strive to process every request as quickly as possible. However, during peak traffic, responses may take slightly longer. Rest assured, your HTTP connection will remain active, and you may continue to receive real-time updates in the following format…
I asked it to turn it "corpospeak like":

  > At DeepSeek, we prioritize accessibility and scalability—which is why we enforce no strict rate limits on API usage. Our systems are designed to handle all requests with high availability, though during peak operational loads, response times may experience nominal delays. Rest assured, your connection will remain active, and responses will continue streaming in real time with the following structure:
... This is Google Translate from GP -> DeepSeek Web. I don't think DeepSeek is a perfectly knowledgeable English speaker in China. "However, during peak traffic," is basically a word substitution on "但是,当服务器流量压力大时", if my Han Script reading is right. Parts of the corpo version like "response times may experience nominal delays." still shows Chinese accent, assuming that's the part you think must be thoroughly washed off.

What you're asking needs English-first bilingual human person who can be trusted and has tech backgrounds. That's quite a tall order.

Re: A critical look at MCP

#323

Earlier quoted context omitted.

Are you a native English speaker? "does NOT constrain user's rate limit" should be "does NOT rate limit incoming requests" or similar. "We will try out best" should be "our best". "when our servers are under high traffic pressure" is at least grammatical, but it's awkward. Normally you'd say "when our servers are dealing with high load" or something similar. "your requests may take some time to receive a response fro…

If your problem is that the texts you quoted were not written by someone with English as the first language, I tell you: English is not the framework of human civilization, it sometimes uses English for data quantization and message passing. A lot of English native speakers has such assumptions that: - any academic topics are universally discussed in English/Latin and so every highly educated person shall speak good…

I don't really get the point of your post.

The goal is to pretend that DeepSeek doesn't have access to good English translators? Or good English translation capabilities?

Why don't we just not pretend this instead?

Re: A critical look at MCP

#324

MCP is in a race to be valuable at all. Smarter agents will have no use for it

Because they can design a protocol in the blink of an eye? They can read docs, play with an API and then figure out how to call it?

Not sure about designing a protocol, but they will be able to use things like we do

Re: A critical look at MCP

#325
post #86
post #45

Earlier quoted context omitted.

Agree... this is an important blog. People need to press pause on MCP in terms of adoption...it was simply not designed with a solid enough technical foundation that would make it suitable to be an industry standard. People are hyped about it, kind of like they were for LangChain and many other projects, but people are going to gradually (after diving into implementations) that it's not actually what they were lookin…

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.

Re: A critical look at MCP

#326

Earlier quoted context omitted.

Certainly a shame if true, there are some really sharp folks at Anthropic and this is an important building block in the emerging ecosystem.

In my experience AI startups are AI maximalists. They use AI for everything they can. AI meeting summarizations, AI search (Perplexity), AI to write code and contracts, AI to perform SEO, AI to recruit candidates, etc. So I 100% believe they would use AI to write specs.

Seems like many are dreading our near future. Not I, I can't wait to see how this all plays out...

Re: A critical look at MCP

#327

Earlier quoted context omitted.

If your problem is that the texts you quoted were not written by someone with English as the first language, I tell you: English is not the framework of human civilization, it sometimes uses English for data quantization and message passing. A lot of English native speakers has such assumptions that: - any academic topics are universally discussed in English/Latin and so every highly educated person shall speak good…

I don't really get the point of your post. The goal is to pretend that DeepSeek doesn't have access to good English translators? Or good English translation capabilities? Why don't we just not pretend this instead?

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 differences and those are just wrong. Languages are at least CODEC. And if you go back to the original topic from there, I don't think it will sound so unreasonable that translating between different CODECs will induce losses and artifacts.

Re: A critical look at MCP

#328
post #136

Earlier quoted context omitted.

I didn’t believe you before clicking the link, but hot damn. That reads like the ideas I scribbled down in school about all the cool projects I could build. There is literally zero substance in there. Amazing.

I thought it was just me. When I first saw all the hype around MCP I went to go read this mess and still have no idea what MCP even is.

It's JSON-RCP 2 with a specific life cycle and events. https://www.jsonrpc.org/specification

I found an explanation on a site once but haven't found any official docs. I suppose you could reverse enegiener the SDKs.

Re: A critical look at MCP

#329

Earlier quoted context omitted.

I don't really get the point of your post. The goal is to pretend that DeepSeek doesn't have access to good English translators? Or good English translation capabilities? Why don't we just not pretend this instead?

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.

Re: A critical look at MCP

#330
post #207
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.

I don’t mind those, tbh (maybe because I came to Python from C and Lisp).

Contrary, I dislike NumPy’s decision to make reduce/accumulate methods of operations (e.g. np.add.reduce and np.mul.accumulate), not higher order functions or methods of NumPy arrays.

Post reply on HN