Live data from Hacker News

A critical look at MCP

raz.sh

231–240 of 348 posts

Re: A critical look at MCP

#231

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…

I live in Japan, and when you read English texts here (it doesn’t really matter if it’s a restaurant menu, a pamphlet at a touristic area, a flyer for local government services…) the same English word will often be written differently within the same document (eg for a recent one I saw: “curbside” was spelled “crubside” and “carbside”).

I always wonder how that happens, because the documents themselves often smell strongly of machine translation - but if they’re machine translated, how would those mistakes get in? My best guess is that there’s a human manually typing out a machine translation output, which kind of boggles the mind.

I think us computer nerds who are used to using computers to do work efficiently have a hard time imagining all the weird ways in which non-computer nerds actually use computers.

Re: A critical look at MCP

#232
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.

Isn't that what a lot of this is about? It's a blue ocean and everyone are full of fomo.

Software quality be damned!

Re: A critical look at MCP

#233

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.

someone is going to write an MCP adaptor that lets Claude use OpenAPI and then we can forget that MCP was a thing

How would that even work?

Re: A critical look at MCP

#234

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…

It may have been A/B tested, and people do prefer the "INTIMATE SERVICE" version more...

Re: A critical look at MCP

#235

MCP should just have been stateless HTTP to begin with. There is no good reason for almost any of the servers I have seen to be stateful at the request/session level —- either the server carries the state globally or it works fine with a session identifier of some sort.

I don't claim to have a lot of experience on this but my intuition tells me that a connection that ends after the request needs to be reopened for the next request. What is more efficient, keeping the session open or closing it, depends on the usage pattern, how much memory does the session consume, etc. etc.

That's not "stateful" for the purposes of correctness. Reusing a tcp stream doesn't make a protocol stateful.

Re: A critical look at MCP

#236

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…

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 easily call her fluent.

Re: A critical look at MCP

#237

Earlier quoted context omitted.

If you know JSON-RPC: it's a JSON-RPC wrapper exposed for AI use and discovery. If you know REST / http request: it's single endpoint-only, partitioned / routed by single "type" or "method" parameter, with some different specification, for AI.

Wasn't the point of REST supposed to be runtime discoverability though? Of course REST in practice just seems to be json-rpc without the easy discoverability which seems to have been bolted on with Swagger or whatnot. But what does MCP do that (properly implemented) REST can't?

Half the point of MCP is just making it easy for an LLM to use some language in a standard way to talk to some other tool. I mean MCP is partly a standard schema for tools to interact and discover each other, and part of it is just allowing non-webserver based communication (like stdio piping, especially useful since initial the use case is running local scripts

Re: A critical look at MCP

#238

Earlier quoted context omitted.

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…

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.

Re: A critical look at MCP

#239
post #129
post #96

Earlier quoted context omitted.

Idk, I'm kind of agnostic and ended up throwing it in there. Regurgitating the OAuth draft don't seem that usefull imho, and why am I forced into it if I'm using http. Seems like there are plenty of usecases where un-attended thing would like to interact over http, where we usually use other things aside from OAuth. It all probably could have been replaced by - The Client shall implement OAuth2 - The Server may imple…

For local servers this doesn't matter as much. For remote servers - you won't really have any serious MCP servers without auth, and you want to have some level setting done between client and servers. OAuth 2.1 is a good middle ground. That's also where, with the new spec, you don't actually need to implement anything from scratch. Server issues a 401 with WWW-Authenticate, pointing to metadata for authorization serv…

[deleted]

Re: A critical look at MCP

#240
> Be honest... when was the last time you ran pip install and didn't end up in dependency hell?

Never? If you use proper encapsulation (e.g. tools such as pipx or using virtual environments), that's a non-issue. It only gets bad when there's Python version incompatibilities

Post reply on HN