Live data from Hacker News

MCP: An in-depth introduction

speakeasy.com

61–70 of 96 posts

Re: MCP: An in-depth introduction

#61
post #48
post #47

It's a half-baked, rushed out, speculative attempt to capture developer mindshare and establish an ecosystem/moat early in a (perceived) market. It's a desperate "standard" muscled in by Amazon/Claude, similar to their overwrought "Smithy" IDL that basically nobody outside the Amazon SDK team chooses to use for API/Schema management. It will end up in that same niche in the long term, most likely... AWS/Amazon/Claude…

Except that in just six months there are literally thousands of MCP servers out there in use. Will it be supplanted? Perhaps. But it's not going to die a natural death.

Yes it is gaining traction. It is still bad. And it will probably not improve as the spec will only add things to try to fix it but it should remove.

Re: MCP: An in-depth introduction

#62
post #3

Earlier quoted context omitted.

This is a VFAQ https://hn.algolia.com/?q=what+is+mcp But to save you the click & read: it's OpenAPI for LLMs

OpenAPI for LLMs is such a good way to describe it!

it's so apt that one of the most common question/statements I hear is why not use OpenAPI? I don't know the answer. Or WTF is streaming HTTP? Sure feels like we're trying to reinvent web sockets. It must be either #notinventedhere or while the genius devs build the LLMs the interns do the documentation and SDKs

Re: MCP: An in-depth introduction

#63

Earlier quoted context omitted.

MCP is a kitchen sink of anti-patterns. There's no way it's not forgotten in a year, just like Langchain will be

what's the problem with Langchain? still super hot to me though I did not use it myself, yet.

> still super hot to me though I did not use it myself, yet.

try it and you'll figure out

Re: MCP: An in-depth introduction

#65
One confusing thing to me was the word "server". An "MCP server" is a server to the LLM "client". But the MCP server itself is a client to the thing it's connecting the LLM to. So it's more like an adapter or proxy. Also I was confused because often this server runs on your local system (although it doesn't have to). In my mind I thought if they're calling it a server it must be run in the cloud somewhere but that's often not the case.

Re: MCP: An in-depth introduction

#66
post #47

It's a half-baked, rushed out, speculative attempt to capture developer mindshare and establish an ecosystem/moat early in a (perceived) market. It's a desperate "standard" muscled in by Amazon/Claude, similar to their overwrought "Smithy" IDL that basically nobody outside the Amazon SDK team chooses to use for API/Schema management. It will end up in that same niche in the long term, most likely... AWS/Amazon/Claude…

MCP and Smithy aren’t comparable. Smithy is an internal tool used by almost every single team (it is used far, far more widely than just the SDK teams) at Amazon to define APIs and generate API servers/clients. It was released publicly because “why not?”, but I assure you that Amazon doesn’t care if you use it or not.

the branding is uncanny https://smithery.ai

Re: MCP: An in-depth introduction

#67
Anyone who has worked with LLMs for non-trival tasks know how poorly they handle JSON vs other formats (they do notably well with XML for some reason but even YAML seems to be handled fine).

MCP forcing JSON for tool specifications seems like a massive mistake.

Maybe Google can save us with something built on top of protobuffs.

Re: MCP: An in-depth introduction

#68
post #6
post #4

"“MCP is an open protocol that standardizes how applications provide context to LLMs, what’s the problem?”" We are already off to a wrong start, context has a meaning specific to LLMs, everyone who works with LLMs knows what it means: the context is the text that is fed as input at runtime to LLM, including the current message (user prompt) as well as the previous messages and responses by the LLM. So we don't need t…

This is a really shallow dismissal, and I say that as someone who is outspokenly critical of MCP [0]. As you yourself say, the context is the text that is fed as input at runtime to an LLM. This text could just always come from the user as a prompt, but that's a pretty lousy interface to try to cram everything that you might want the model to know about, and it puts the onus entirely on the user to figure out what mi…

But that's not what MCP does. It is a tool created by anthropic ( 2nd most used LLM) to provide portabiliry and vendor neutrality between different LLMs. It's like terraform for LLMs.

Also providing data through function calls/tool use is not context, you are overloading the term. Context is LLM context, if you fetch from a db it's something else

Re: MCP: An in-depth introduction

#69
post #2

I feel like I need the opposite, a cursory view, or at least a definition. Most of the material on MCP is either too specific or too in depth. WTF is it?! (Other than a dependency by Anthropic)

look at the implementation here, https://modelcontextprotocol.io/quickstart/client that's the missing piece in most of these description. You send off a description of the tools, the model decides if it wants to use one, then you run it with the args, send it back to the context and loop.

Terraform for LLMs

Re: MCP: An in-depth introduction

#70

One confusing thing to me was the word "server". An "MCP server" is a server to the LLM "client". But the MCP server itself is a client to the thing it's connecting the LLM to. So it's more like an adapter or proxy. Also I was confused because often this server runs on your local system (although it doesn't have to). In my mind I thought if they're calling it a server it must be run in the cloud somewhere but that's…

Reminds me of X11server
Post reply on HN