| ▲ | nater5000 5 hours ago |
| This is too dense. You might as well just post some Python code with sufficient comments to get the same point across. I think a nicely written article with a few diagrams would go a long way. Sometimes less is more. MCPs don't really need this level of technical explanations (it's basically just a REST API with standardized endpoints for discovery aimed at agents), and AI agents really do lack in the taste dimension when it comes to these things. |
|
| ▲ | jrmg 4 hours ago | parent | next [-] |
| Yeah, this feels like one of those ‘explainers’ that feel like they are great to someone who already knows how the system works, but don’t actually work for newbies because they tacitly assume knowledge of the shape of the system that seems ‘obvious’ to someone steeped in it. |
| |
| ▲ | bityard 3 hours ago | parent [-] | | This is a problem with most docs I encounter. _Good_ documentation should also teach the user how to use the thing, not simply end up as glorified out-of-band code comments. | | |
| ▲ | Geezus_42 3 hours ago | parent [-] | | I found that it's a mistake I would often make when writing documentation about something I deeply understand. I forget the questions that led me to that understanding. Now I make a conscious effort to think about the knowledge of the intended audience. I still miss things, but that's why it's good to have other people review. |
|
|
|
| ▲ | Aurornis 3 hours ago | parent | prev | next [-] |
| > it's basically just a REST API The opening has 1 paragraph and 5 table entries. One of them is “Not REST” It’s a little scary that this was considered too dense or complex because the basics were explained in something that could be read in 1 minute. That still wasn’t enough to stop the top HN comment (as I write this) from calling it too dense and giving incorrect information that is immediately refuted by skimming the top part of the article. |
| |
| ▲ | sharifhsn 3 hours ago | parent | next [-] | | It is not technically REST, but it is basically REST. The alternative to a server endpoint is JSON-RPC over stdin which has the same request/response format as REST. This is exactly the point about over-complicating it by saying "it's not REST, it's not JSON-RPC". It's a JSON request/response protocol with a defined format. | | | |
| ▲ | wongarsu 2 hours ago | parent | prev | next [-] | | The opening is fine, but when you click "Start the lessons" you get a six-pane interface that imho is pretty overwhelming Yeah, I can click around and follow what's going on. But I'm with GP: this is not making it easier to understand. It's great at being Hollywood UX: looks pretty, stuff moving everywhere. One click on "step" makes the image animate, and change the text in the left sidebar, top middle, and right sidebar, in addition to stepping the table in the bottom middle. But it's almost the opposite of distilling information | | |
| ▲ | steve_adams_86 18 minutes ago | parent [-] | | > you get a six-pane interface that imho is pretty overwhelming Agreed, and it probably doesn't need to be overwhelming but the design choices leave the intent and purpose of the UI fairly unclear. It requires a bit of clicking around to understand what it's all for, and it's quite flat and unappealing, leaving little drive to do that work. |
| |
| ▲ | iugtmkbdfil834 2 hours ago | parent | prev | next [-] | | Sign of times man. Not that long ago -- on HN mind you -- someone posted an article that landed on main page that used lsblk as some sort of secret hacker linux command. | |
| ▲ | parineum 3 hours ago | parent | prev | next [-] | | That's the purpose of the comment, to make a comparison that's simpler than the article that is missing from the article. If the article said, "It's basically just REST". There'd be no need to comment as such. | |
| ▲ | sleepybrett an hour ago | parent | prev | next [-] | | This is actually one of the better 'mcp explained' type 'articles' i've read. | |
| ▲ | taneq 3 hours ago | parent | prev | next [-] | | While we’re applauding brevity, three cheers for the first line being “model context protocol”. While yes, this one is common, it’s still nice not having to scroll through 20 screens of blah to still not find out what the thing is. | |
| ▲ | flanz_10 an hour ago | parent | prev [-] | | > The opening has 1 paragraph and 5 table entries. One of them is “Not REST” and yet... |
|
|
| ▲ | dingaling911 4 hours ago | parent | prev | next [-] |
| It's literally JSON-RPC I'm not sure why you say it's a REST API. It's not even close to a REST API. |
| |
| ▲ | WhitneyLand 4 hours ago | parent | next [-] | | In this context/application I see a lot of similarities. They both provide stateless RPC methods and human readable metadata that makes them easy to route. You could ask why json-rpc was even necessary for 2.0. I think mostly just for stdio and backwards compatibility. | | |
| ▲ | dingaling911 3 hours ago | parent [-] | | In the venn diagram of MCP and REST, there is an (optional) overlap for sure but one does not subsume the other. |
| |
| ▲ | 3 hours ago | parent | prev [-] | | [deleted] |
|
|
| ▲ | amelius 3 hours ago | parent | prev | next [-] |
| > This is too dense. Maybe it was written for an AI? :) Or by an AI? Or both? |
|
| ▲ | WhitneyLand 4 hours ago | parent | prev | next [-] |
| To me the writing itself seems pretty economical. From your comment, I expected to be annoyed by a bunch of slop or obscurities. My guess is the writing did not come straight out of an LLM and was carefully curated. If I’m wrong I’d love to have the style prompt. |
|
| ▲ | rwilinski 3 hours ago | parent | prev [-] |
| [flagged] |
