Live data from Hacker News

Model Context Protocol

anthropic.com

221–230 of 283 posts

Re: Model Context Protocol

#221

Earlier quoted context omitted.

This is a great idea! There's also the matter of requests' result types not being automatically inferred in the SDK right now, which would be great to fix. Could I convince you to submit a PR? We'd love to include community contributions!

If you were willing to bring additional zod tooling or move to something like TypeBox ( https://github.com/sinclairzx81/typebox ), the json schema would be a direct derivation of the tools' input schemas in code.

The json-schema-to-ts npm package has a FromSchema type operator that converts the type of a json schema directly to the type of the values it describes. Zod and TypeBox are good options for users, but for the reference implementation I think a pure type solution would be better.

Re: Model Context Protocol

#222

The default transport should have accommodated binary data. Whether it’s tensors of image data, audio waveforms, or pre-tokenized NLP workloads it’s just going to hit a wall where JSON-RPC can’t express it uniquely and efficiently.

This is a really, really, good point.

Devil's advocating for conversation's sake: at the end of the day, the user and client app want very little persistent data coming from the server - if nothing else than the client is expecting to store chats as text, with external links or Potemkin placeholders for assets like files.

Re: Model Context Protocol

#223

In case anyone else is like me and wanted to try the filesystem server before anything else, you may have found the README insufficient. You need to know: 1. The claude_desktop_config.json needs a top-level mcpServer key, as described here: https://github.com/modelcontextprotocol/servers/pull/46/comm... 2. If you did this correctly the, after you run Claude Desktop, you should see a small 'hammer' icon (with a number…

Yeah this was a huge foot gun

Re: Model Context Protocol

#224
post #206

@jspahrsummers and I have been working on this for the last few months at Anthropic. I am happy to answer any questions people might have.

Why not use GraphQL instead of inventing a whole new protocol?

That's just quibbling about the details of moving data from point A to point B. You're inventing a new protocol either way.

Re: Model Context Protocol

#225
If you run a SaaS and want to rapidly build out a CLI that you could plug into this ~and~ want something that humans can use, check out the project I’ve been working on at https://terminalwire.com

tl;dr—you can build & ship a CLI without needing an API. Just drop Terminalwire into your server, have your users install the thin client, and you’ve got a CLI.

I’m currently focused on getting the distribution and development experience dialed in, which is why I’m working mostly with Rails deployments at the moment, but I’m open to working with large customers who need to ship a CLI yesterday in any language or runtime.

If you need something like this check it out at https://terminalwire.com or ping me brad@terminalwire.com.

Re: Model Context Protocol

#226

Earlier quoted context omitted.

I don't even know what to respond/what this is asking.

I think they meant that your unprompted declaration of having understood the feature, followed by giving no apparent insight into it is odd and something reminiscent of a bot. Your entire comment could just be “Here’s the quickstart guide: ” and literally no useful information would be lost. A human would topically say: “I spent some time understanding the feature and I think I got it. Here the quickstart: ” Or perha…

[deleted]

Re: Model Context Protocol

#227

@jspahrsummers and I have been working on this for the last few months at Anthropic. I am happy to answer any questions people might have.

I read through several of the top level pages, then SQLite, but still had no idea what was meant by "context" as it's a highly ambiguous word and is never mentioned with any concrete definition, example, or scope of capability that it is meant to imply. After reading the Python server tutorial, it looks like there is some tool calling going on, in the old terminology. That makes more sense. But none of the examples s…

At first glance it seems to be a proposed standard interface and protocol for describing and offering an external system to the function calling faculity of an LLM.

Re: Model Context Protocol

#228

Earlier quoted context omitted.

I don't even know what to respond/what this is asking.

I think they meant that your unprompted declaration of having understood the feature, followed by giving no apparent insight into it is odd and something reminiscent of a bot. Your entire comment could just be “Here’s the quickstart guide: ” and literally no useful information would be lost. A human would topically say: “I spent some time understanding the feature and I think I got it. Here the quickstart: ” Or perha…

I don't think the wording was unclear. It's obviously their own article.

Re: Model Context Protocol

#229
A picture is worth a 1k words.

Is there any good arch diagram for one of the examples of how this protocol may be used?

I couldn’t find one easily…

Re: Model Context Protocol

#230

Earlier quoted context omitted.

It's just function calling with a new name and a big push from the LLM provider, but this time it's in the right direction . Contrast with OpenAI's "GPTs", which are just function calling by another name, but pushed in the wrong direction - towards creating a "marketplace" controlled by OpenAI. I'd say that thing you're feeling comes from witnessing an LLM vendor, for the first time in history, actually being serious…

But either way the interface is just providing a json schema of functions along with your chat completion request, and a server with ability to parse and execute the response. I’m not really seeing where a new layer of abstraction helps here (much less a new “protocol”, as though we need a new transport layer? It smells like the thinking is that you (the developer) can grab from a collection of very broad data connec…

> It smells like the thinking is that you (the developer) can grab from a collection of very broad data connectors, and the agent will be able to figure out what to do with them without much custom logic in between.

This has always been the idea behind tools/function calling in LLMs.

What MCP tries to solve is the NxM problem - every LLM vendor has their own slightly different protocols for specifying and calling tools, and every tool supplier has to handle at least one of them, likely with custom code. MCP aims to eliminate custom logic at the protocol level.

Post reply on HN