Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

MCP: An in-depth introduction

speakeasy.com

Post reply on HN
Print view View original

81–90 of 96 posts

Re: MCP: An in-depth introduction

#81

Post by pcwelder »

CSMastermind wrote: post #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.

Good MCP clients avoid having LLMs generate JSON.

Claude for example uses XML to generate mcp tool usage. At least top level strings don't need to be json encoded.

Re: MCP: An in-depth introduction

#82

Post by iLoveOncall »

throwaway314155 wrote: post #78
iLoveOncall wrote: post #75

Earlier quoted context omitted.

Not more than what local servers do. You don't seem to understand what MCP is. Regardless of whether the MCP "server" is local or remote, it is JUST a wrapper around APIs. It's basically a translation layer to make your APIs adhere to the MCP spec, that's it. Whether that wrapper's code runs on your laptop or a remote server changes nothing in terms of data exfiltration capabilities. If anything, it would make it mor…

Right but at least in the case of a local instance, the risk profile is shifted to the use of the computer. A less than ideal situation for sure, but on the other hand a user should be able to do just about anything they want to with hardware they own.

I'm talking about MCP servers that call 3rd party APIs, like your local MCP server calling the Jira instance of your company, the Google Maps API, etc.

Obviously local MCP servers make sense to interact with applications that you have installed locally, but that's by far not their only use.

Re: MCP: An in-depth introduction

#83

Post by TZubiri »

lolinder wrote: post #72
TZubiri wrote: post #68

Earlier quoted context omitted.

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

> 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. Given that your only contributions in this thread are to acknowledge your ignorance of MCP [0] and to post the summary dismissal upthread that shows your ignorance of it, it would probably behoove you to actually learn about MCP more…

If you believe this then you don't understand how tool use is implemented. It's literally accomplished by injecting a tool's response into the context [1].

I was doing tool use before chatgpt released an official API for function calls. You literally give ChatGPT API specs and ask it to generate call parameters.

The API is fed into the LLM as context, the response is part of the output. Whether you pass that output through another layer of LLM is trivial. And even if you do, the "context" in that case would be only the response, not the whole database. You are confusing even yourself, you accepting the overloading of the word 'context' (pushed by a company for commercial purposes) and you are now unable to distinguish between LLM context in terms of tokens, an external data source, and a response fetched by the tool.

It's not that I am ignorant of what Anhtropic claims Context means, I'm contesting it. If Microsoft releases a new product and claims that Intelligence is the parameters of their Microsoft Product, then it pays to be a bit cynical instead of parroting whatever they say like some unpaid adman

Re: MCP: An in-depth introduction

#84

Post by what »

amannm wrote: post #66
placardloop wrote: post #50

Earlier quoted context omitted.

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

Uh, I’m pretty sure that’s a completely unrelated directory of MCP servers. https://aws.amazon.com/blogs/developer/introducing-smithy-id...

Re: MCP: An in-depth introduction

#85

Post by bandoti »

owebmaster wrote: post #59
lolinder wrote: post #58

Earlier quoted context omitted.

It's a pretty bad spec that has a lot of artifacts of having been generated by an LLM. But at least it exists!

Yeah it is not a well thought spec. There is a big confusion about what is a MCP Client and what is a MCP Host. Which is a useless separation as what they call in the spec a client is just a connection to a server while MCP host is what is a real client (the apps using MCP like claude desktop, cli tools, etc).

But the host application does much more than just connect to MCP servers, as the host is one-to-many client connections. The host application also has OTHER client connections to AI agents and so-forth.

I think it can be confusing in general it’s like understanding X11 where the client-server relationship is conceptually flipped. :)

Re: MCP: An in-depth introduction

#86

Post by lolinder »

TZubiri wrote: post #83
lolinder wrote: post #72

Earlier quoted context omitted.

> 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. Given that your only contributions in this thread are to acknowledge your ignorance of MCP [0] and to post the summary dismissal upthread that shows your ignorance of it, it would probably behoove you to actually learn about MCP more…

If you believe this then you don't understand how tool use is implemented. It's literally accomplished by injecting a tool's response into the context [1]. I was doing tool use before chatgpt released an official API for function calls. You literally give ChatGPT API specs and ask it to generate call parameters. The API is fed into the LLM as context, the response is part of the output. Whether you pass that output t…

I couldn't care less about Anthropic or MCP—as I noted, I'm a critic of MCP—but pedants bug me quite a bit especially when they're wrong.

> The API is fed into the LLM as context, the response is part of the output.

So you implement tool use by feeding an API into the LLM as context in order to get it to produce call parameters. Got it.

> Whether you pass that output through another layer of LLM is trivial. And even if you do, the "context" in that case would be only the response

So the output of the tool when called with those parameters can be fed back into the LLM as further context. Got it.

Given the above, it seems that we agree that tool use is implemented entirely by giving selected bits of context to the model.

With that in mind, if one were to design a protocol that makes tool use plug-and-play instead of something that has to be coded by hand for each tool—a protocol designed to allow a model to discover tool APIs that it might want to bring into context and then use those APIs to bring their outputs into context—it would be reasonable to call said protocol the Model Context Protocol, because it's all about getting specific bits of Context into a Model.

I'm not sure why the word "context" is the hill you decided to die on here when there is so much else to pick on with MCP, but it's time to get off the hill.

Re: MCP: An in-depth introduction

#87

Post by TZubiri »

lolinder wrote: post #86
TZubiri wrote: post #83

Earlier quoted context omitted.

If you believe this then you don't understand how tool use is implemented. It's literally accomplished by injecting a tool's response into the context [1]. I was doing tool use before chatgpt released an official API for function calls. You literally give ChatGPT API specs and ask it to generate call parameters. The API is fed into the LLM as context, the response is part of the output. Whether you pass that output t…

I couldn't care less about Anthropic or MCP—as I noted, I'm a critic of MCP—but pedants bug me quite a bit especially when they're wrong. > The API is fed into the LLM as context, the response is part of the output. So you implement tool use by feeding an API into the LLM as context in order to get it to produce call parameters. Got it. > Whether you pass that output through another layer of LLM is trivial. And even…

That something can be context if you feed it as input to the LLM and that output will be input, is true for everything in an LLM. So you are not really conveying any meaning with that definition of MCP. MCP is an API layer between LLMs and SaaS applications, designed to provide vendor neutrality for the LLMs. Nothing to do with the context window, which is a specific variable measured in kTokens

It pays to be precise when speaking and studying, and it pays to develop a precise language on nascent technologies when we comunicate about them.

This reminds me when I was studying chemistry and I thought they were pedantic for the way they used the word salt. Or when I studied chess and I called every bishop and knight attack to the f6 pawn the fried liver, instead of the specific sequence of moves that we call the fried liver. Or when I thought that the arm forearm distinction was pedantic in medicine

Science demands precision in communication, feel free to steal a well defined term and use it to mean something else that already has a different sign to denote it. But I'm not playing

Re: MCP: An in-depth introduction

#88

Post by TZubiri »

jredwards wrote: post #12
TZubiri wrote: 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…

Well, that's the worst take I've seen all week, and it's Friday. Agent LLMs are able to retrieve additional context and MCP servers give them specific, targeted tools to do so.

You are uncritically parroting the primary source.

Re: MCP: An in-depth introduction

#89

Post by troupo »

lsaferite wrote: post #30
troupo wrote: post #15

Earlier quoted context omitted.

It's a vibe-coded protocol that lets LLM models query external tools. You write a wrapper ("MCP server") over your docs/apis/databases/sites/scripts that exposes certain commands ("tools"), and you can instruct models to query your wrapper with these commands ("calling/invoking tools") and expect responses in a certain format that they can then use. That is it. Why vibe-coded? Because instead of bi-directional websoc…

You are complaining about the transport aspect of the specification. The protocol could easily be transported over websockets. Heck, since stdio is one transport, you could simply pipe that over websockets. Of course, that leaves a massive gap around authn and authz. The Streamable HTTP transport includes an authentication workflow using OAuth. Of course, that only addresses part of the issue. There are many flaws th…

The choice of transport is just one, quite telling, aspect of this mess.

Could these commands be executed over websockets? Yes, they could. Will they? No, because the specification literally only defines two transports, and all of the clients only support those.

As with any hype, the authors drink their own coolaid, invent their own terminology, and ignore literally everything that came before them.

Even reading through explanations on the once again vibe-coded https://modelcontextprotocol.io/ you can't help to wonder why.

"tools" are nothing but RPC calls (that's why the base of this is JSON RPC)

"resources"? PHP could do an fopen on remote URLs in the 90s. It literally is just that: "Each resource is identified by a unique URI and can contain either text or binary data." You don't say.

"sampling"? It literally is just bi-directional communication. "servers request data from the client by sending commands". What a novel idea, must have a new name and marketing blurb about "powerful MCP feature, enabling sophisticated agentic behaviors while maintaining security and privacy."

As for auth, again, MCP doesn't have it, and expects you to just figure it out yourself. The entirety of the "spec" on it is just "MCP provides an Authorization framework for use with HTTP and your expected to conform to this spec". There's no spec. Edit: to be clear. At the point of writing all mentions of "MCP Auth Spec" on the internet link to https://modelcontextprotocol.io/specification/2025-03-26 which at the time of writing contains zero mentions of OAuth and says nothing about auth (and is not a spec to begin with) [1]

And so on.

It's hype-driven vibe-coded development at its finest.

[1] The auth spec is here: https://modelcontextprotocol.io/specification/2025-03-26/bas... I don't think anything on the site links to this directly. I found the link from some github discussion. See issues with it here: https://blog.christianposta.com/the-updated-mcp-oauth-spec-i...

Re: MCP: An in-depth introduction

#90

Post by owebmaster »

bandoti wrote: post #85
owebmaster wrote: post #59

Earlier quoted context omitted.

Yeah it is not a well thought spec. There is a big confusion about what is a MCP Client and what is a MCP Host. Which is a useless separation as what they call in the spec a client is just a connection to a server while MCP host is what is a real client (the apps using MCP like claude desktop, cli tools, etc).

But the host application does much more than just connect to MCP servers, as the host is one-to-many client connections. The host application also has OTHER client connections to AI agents and so-forth. I think it can be confusing in general it’s like understanding X11 where the client-server relationship is conceptually flipped. :)

> But the host application does much more than just connect to MCP servers, as the host is one-to-many client connections. The host application also has OTHER client connections to AI agents and so-forth.

Yes, that is the case, but they could have called just connections, a MCP Client (host) keeps multiple open connections to MCP servers. Everywhere in the docs and in the internet peoplE MCP Client the app connecting to mcp servers, not MCP hosts.

Post reply on HN