Model Context Protocol • Hacker News Board

Re: Model Context Protocol

#121

Post by jspahrsummers » Mon, Nov 25, 2024, 9:53 PM UTC

threecheese wrote: post #112

WRT prompts vs sampling: why does the Prompts interface exclude model hints that are present in the Sampling interface? Maybe I am misunderstanding. It appears that clients retrieve prompts from a server to hydrate them with context only, to then execute/complete somewhere else (like Claude Desktop, using Anthropic models). The server doesn’t know how effective the prompt will be in the model that the client has acce…

Our thinking is that prompts will generally be a user initiated feature of some kind. These docs go into a bit more detail:

https://modelcontextprotocol.io/docs/concepts/prompts

https://spec.modelcontextprotocol.io/specification/server/pr...

… but TLDR, if you think of them a bit like slash commands, I think that's a pretty good intuition for what they are and how you might use them.

Re: Model Context Protocol

#122

Post by ssfrr » Mon, Nov 25, 2024, 9:56 PM UTC

I'm a little confused as to the fundamental problem statement. It seems like the idea is to create a protocol that can connect arbitrary applications to arbitrary resources, which seems underconstrained as a problem to solve.

This level of generality has been attempted before (e.g. RDF and the semantic web, REST, SOAP) and I'm not sure what's fundamentally different about how this problem is framed that makes it more tractable.

Re: Model Context Protocol

#123

Post by [deleted] » Mon, Nov 25, 2024, 9:58 PM UTC

killthebuddha wrote: post #84

I see a good number of comments that seem skeptical or confused about what's going on here or what the value is. One thing that some people may not realize is that right now there's a MASSIVE amount of effort duplication around developing something that could maybe end up looking like MCP. Everyone building an LLM agent (or pseudo-agent, or whatever) right now is writing a bunch of boilerplate for mapping between mes…

[deleted]

Re: Model Context Protocol

#124

Post by [deleted] » Mon, Nov 25, 2024, 9:58 PM UTC

ssfrr wrote: post #122

I'm a little confused as to the fundamental problem statement. It seems like the idea is to create a protocol that can connect arbitrary applications to arbitrary resources, which seems underconstrained as a problem to solve. This level of generality has been attempted before (e.g. RDF and the semantic web, REST, SOAP) and I'm not sure what's fundamentally different about how this problem is framed that makes it more…

[deleted]

Re: Model Context Protocol

#125

Post by [deleted] » Mon, Nov 25, 2024, 9:58 PM UTC

bionhoward wrote: post #75

I love how they’re pretending to be champions of open source while leaving this gem in their terms of use “”” You may not access or use, or help another person to access or use, our Services in the following ways: … To develop any products or services that compete with our Services, including to develop or train any artificial intelligence or machine learning algorithms or models. “””

[deleted]

Re: Model Context Protocol

#126

Post by faizshah » Mon, Nov 25, 2024, 10:00 PM UTC

So it’s basically a standardized plugin format for LLM apps and thats why it doesn’t support auth.

It’s basically a standardized way to wrap you Openapi client with a standard tool format then plug it in to your locally running AI tool of choice.

Re: Model Context Protocol

#127

Post by gyre007 » Mon, Nov 25, 2024, 10:01 PM UTC

Something is telling me this _might_ turn out to be a huge deal; I can't quite put a finger on what is that makes me feel that, but opening private data and tools via an open protocol to AI apps just feels like a game changer.

Re: Model Context Protocol

#128

Post by thelastparadise » Mon, Nov 25, 2024, 10:11 PM UTC

killthebuddha wrote: post #84

I see a good number of comments that seem skeptical or confused about what's going on here or what the value is. One thing that some people may not realize is that right now there's a MASSIVE amount of effort duplication around developing something that could maybe end up looking like MCP. Everyone building an LLM agent (or pseudo-agent, or whatever) right now is writing a bunch of boilerplate for mapping between mes…

Your point about boilerplate is key, and it’s why I think MCP could work well despite some of the concerns raised. Right now, so many of us are writing redundant integrations or reinventing the same abstractions for tool usage and context management. Even if the first iteration of MCP feels broad or clunky, standardizing this layer could massively reduce friction over time.

Regarding the standalone servers, I suspect they’re aiming for usability over elegance in the short term. It’s a classic trade-off: get the protocol in people’s hands to build momentum, then refine the developer experience later.

Re: Model Context Protocol

#129

Post by gyre007 » Mon, Nov 25, 2024, 10:20 PM UTC

quantadev wrote: post #97

jasonjmcghee wrote: post #68

Earlier quoted context omitted.

Not sure I understand your point. If it's your client / server, you are controlling how they interact, by implementing the necessaries according to the protocol. If you're writing an LSP for a language, you're implementing the necessaries according to the protocol (when to show errors, inlay hints, code fixes, etc.) - it's not deciding on its own.

Even if I could make use of it, I wouldn't, because I don't write proprietary code that only works on one AI Service Provider. I use only LangChain so that all of my code can be used with any LLM. My app has a simple drop down box where users can pick whatever LLM they want to to use (OpenAI, Perplexity, Gemini, Anthropic, Grok, etc) However if they've done something worthy of putting into LangChain, then I do hope L…

It's an open protocol; where did you get the idea that it would only work with Claude? You can implement it for whatever you want - I'm sure langchain folks are already working on something to accommodate it

Re: Model Context Protocol

#130

Post by defnotai » Mon, Nov 25, 2024, 10:21 PM UTC

melvinmelih wrote: post #100

This is great but will be DOA if OpenAI (80% market share) decides to support something else. The industry trend is that everything seems to converge to OpenAI API standard (see also the recent Gemini SDK support for OpenAI API).

There’s clearly a need for this type of abstraction, hooking up these models to various tooling is a significant burden for most companies.

Putting this out there puts OpenAI on the clock to release their own alternative or adopt this, because otherwise they run the risk of engineering leaders telling their C-suite that Anthropic is making headway towards better frontier model integration and OpenAI is the costlier integration to maintain.