Hacker News new | ask | show | jobs
by teaearlgraycold 442 days ago
MCP is poorly named. That is why it’s confusing to many people. It’s a tool use protocol. It provides means to list tools provided by a server as well as manage asynchronous tasks. It’s transport agnostic and uses JSON-RPC to format requests and responses.

It’s different in that it’s designed to provide natural language instructions to LLMs and is a pretty open-ended protocol. It’s not like the Language Server Protocol which has all of its use cases covered in the spec. MCP gives just a little bit of structure but otherwise is built to be all things for all people. That makes it a bit hard to parse when reading the docs. I think they certainly could do a better job in communicating its design though.
3 comments
Spivak 441 days ago
I think it makes more sense to think of them as agent software plugins than a protocol that makes sense in isolation. The reason for its existence is because you want your <thing> to work with someone's AI agent. You write some code, your user integrates it with their local software and you provide data to it in the format that it's expecting and do stuff when asked.
link
daxfohl 439 days ago
https://github.com/block/goose tutorials page finally made it click for me. Concrete examples. Anthropic should link directly out to that from their docs.
link
lsaferite 441 days ago
The MCP documentation has a long way to go to be really easy to grok for everyone.

One aspect I 'missed' the first few times I read over the spec was the 'sampling' feature on the client side which, for anyone that hasn't read the spec, is a way for the MCP Client to expose an LLM endpoint to the MCP Server for whatever the server may need to do.

Additionally, I feel like understanding around the MCP Server 'prompts' feature is also a bit light.

Overall, MCP is exciting conceptually (when combined with LLM Tool Support), but it's still a fast-moving space and there will be a lot of growing pains.

link
daxfohl 442 days ago
Yeah, some more concrete examples would help. LSP docs make a lot more sense in that they lay out the problems that it solves: the many-to-many issue and the redundant-implementations-of-parsers-for-a-language issue. Maybe the USB(-C?) comparison is more apt, though I imagine most software engineers know less about that one. And IIUC the "-C" is just a physical component and not part of the protocol(?)

Anyway, sounds like we'll see a v2 and v3 and such of the protocol before long, to deal with some of the issues in the article.

link