Earlier quoted context omitted.
I think it works because json is verbose and reinforces what everything is in each record.
From this point of view XML offers all that and named brackets.
True. Even better with inline attributes.
A critical look at MCP
141–150 of 348 posts
Re: A critical look at MCP
#142Earlier 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.
This article feels like an old timer who knows WebSockets just doesn't want to learn what SSE is. I support the decision to ditch WebSockets because WebSockets would only add extra bloat and complexity to your server, whereas SSE is just HTTP. I don't understand though why have "stdio" transport if you could just run an HTTP server locally.
HTTP call may be blocked by firewalls even internally, and it's overkill to force stdio apps to expose http endpoints for this case only.
As in, how MCP client can access `git` command without stdio? You can run a wrapper server for that or use stdio instead
Re: A critical look at MCP
#143Earlier quoted context omitted.
> Give it more than a couple months though and I think we'll see it mature some more. Or like the early Python ecosystem, mistakes will become ossified at the bottom layers of the stack, as people rapidly build higher level tools that depend on them. Except unlike early Python, the AI ecosystem community has no excuse, BECAUSE THERE ARE ALREADY HISTORICAL EXAMPLES OF THE EXACT MISTAKES THEY'RE MAKING.
Could you throw on a couple of examples of calcified early mistakes of Python? GIL is/was one, I presume?
> early mistakes of Python?
Python.
Re: A critical look at MCP
#144Earlier quoted context omitted.
This article feels like an old timer who knows WebSockets just doesn't want to learn what SSE is. I support the decision to ditch WebSockets because WebSockets would only add extra bloat and complexity to your server, whereas SSE is just HTTP. I don't understand though why have "stdio" transport if you could just run an HTTP server locally.
HTTP call may be blocked by firewalls even internally, and it's overkill to force stdio apps to expose http endpoints for this case only. As in, how MCP client can access `git` command without stdio? You can run a wrapper server for that or use stdio instead
> 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.
Re: A critical look at MCP
#145Agreed with basically the entire article. Also happy to hear that someone else was as bewildered as me when they visited the MCP site and they found nothing of substance. RFCs can be a pain to read, but they're much better than 'please just use our SDK library'.
I wish there was a clear spec on the site but there isn't https://modelcontextprotocol.io/specification/2025-03-26 It seems like half of it is Sonnet output and it doesn't describe how the protocol actually works. For all its warts, the GraphQL spec is very well written https://spec.graphql.org/October2021/
[deleted]
Re: A critical look at MCP
#146It is indeed quite baffline why MCP is taking off, but facts are facts. I would love to be enlightened how MCP is better than an OpenAPI Spec of an existing Server.
I'm not saying MCP is perfect, but it's better than OpenAPI for LLMs for a few reasons. * MCP tools can be described simply and without a lot of text. OpenAPI specs are often huge. This is important because the more context you provide an LLM the more expensive it is to run, and the larger model you need to use to be effective. If you provide a lot of tools then using OpenAPI specs could take up way too much for cont…
> OpenAPI specs are static, but MCP allows for more dynamic tool usage.
This is repeated everywhere, but I don’t get it. OpenAPI specs are served from an HTTP endpoint, there’s nothing stopping you from serving a dynamically rendered spec depending on the client or the rest of the world?
Re: A critical look at MCP
#147This is a part of the bigger problem. Near all of AI is done by mathematicians, (data) scientists, students and amateur enthusiasts. Not by professional software engineers. This is why nearly everything looks like a one weekend pet project by the standards of software engineering.
Speak for yourself. I see the majority of work being done by professional software engineers.
Re: A critical look at MCP
#148Meanwhile I'm happily writing MCP servers that meet my personal needs and installing complex packages over pip. The author seems to have a very narrow concept of what makes acceptable software.
Re: A critical look at MCP
#149Earlier quoted context omitted.
The people who built MCP are seasoned software engineers, as are most folks who work for these labs. What are you even on about?
LOL
Okay, well, clearly you have some funny beliefs, and I won’t try to convince you otherwise. Just think first before posting weird screeds with no basis in reality next time.
Re: A critical look at MCP
#150Meanwhile I'm happily writing MCP servers that meet my personal needs and installing complex packages over pip. The author seems to have a very narrow concept of what makes acceptable software.
I too love to close out bugs with “works for me on my machine”