A Critical Look at "A Critical Look at MCP."

https://news.ycombinator.com/rss Hits: 2
Summary

or, a critical look at "A Critical Look at MCP."​ I came across this post shortly after finishing support for the HTTP Streaming transport on mcp.run. After a week or so of banging my head against the matrix of OAuth RFC support and client transport support, I should be in a sympathetic frame of mind to receive a critique of the protocol. And yet! Here I am, defending MCP. After all, the good that interfaces do oft lay interred with their blemishes. And MCP has blemishes. But I don't think we're in agreement about what they are, and where they pose actual danger to the value that MCP creates. level setting​ First, a bit about mcp.run, to level-set. (And, well, because it's business that sells goods and services -- and, not to put too fine a point on it, one which employs me.) mcp.run is a website that lets you build your own MCP server combined out of a number of other MCP servers. Those servers might be remote connections or they might be written in Wasm and run on your computer, or a combination of the two. Our goal is to make it easier for businesses to adopt MCP tools by handling the configuration and co-location of servers. We're sort of a "virtual" MCP server, in that sense. This is important for two reasons: One, MCP started out as a primarily "on-device" protocol, which meant that your MCP servers would run as a sub-process spawned by your client (Cursor, Windsurf, Claude Desktop, etc.) So delivering MCP servers in Wasm meant that these sub-processes couldn't take unexpected action. It also meant that we could safely host these servers ourselves in preparation for remote server transports to gain client adoption. Two, as we can host all of these servers for you, we can also hold onto any necessary configuration -- OAuth client data, tokens, configuration -- and ensure that it is only accessed on our servers using separately stored encryption keys. As adoption of MCP begins to tilt from "local servers" to "connecting to remote servers", this becomes more appe...

First seen: 2025-05-17 09:46

Last seen: 2025-05-17 10:46