271–280 of 283 posts
Earlier quoted context omitted.
Is it at least somewhat in sync with plans from Microsoft , OpenAI and Meta? And is it compatible with the current tool use API and computer use API that you’ve released? From what I’ve seen, OpenAI attempted to solve the problem by partnering with an existing company that API-fys everything. This feels looks a more viable approach, if compared to effectively starting from scratch.
What's the name of the company that OpenAI's partnered with? Just curious.
Just tried out the puppeteer server example if anyone is interested in seeing a demo: https://x.com/chxy/status/1861302909402861905 . (Todo: add tool use - prompt would be like "go to this website and screenshot") I appreciate the design which left the implementation of servers to the community which doesn't lock you into any particular implementation, as the protocol seems to be aiming to primarily solve the RPC lay…
Earlier quoted context omitted.
Does it give a standard way to approve changes? I wouldn't want to give an LLM access to my database unless I can approve the changes it applies.
It seems to support your ask, as much as a protocol can. Having read all the docs and looked through some code, my mental model is: - A host never talks to a server directly, only via a Client (which is presumably a human). The host has or is the LLM (app). - A server only supplies context data (readonly), in the form of tool call, direct resource URL, or pre populated prompt. It can call back to a client directly, f…
https://github.com/modelcontextprotocol/servers/blob/main/sr...
How can an add on that works with arbitrary "servers" tell the difference between these two tools? Without being able to tell the difference you can't really build a generic way to ask for confirmation in the application that is using the server...
{
name: "create_directory",
description:
"Create a new directory or ensure a directory exists. Can create multiple " +
"nested directories in one operation. If the directory already exists, " +
"this operation will succeed silently. Perfect for setting up directory " +
"structures for projects or ensuring required paths exist. Only works within allowed directories.",
inputSchema: zodToJsonSchema(CreateDirectoryArgsSchema) as ToolInput,
},
{
name: "list_directory",
description:
"Get a detailed listing of all files and directories in a specified path. " +
"Results clearly distinguish between files and directories with [FILE] and [DIR] " +
"prefixes. This tool is essential for understanding directory structure and " +
"finding specific files within a directory. Only works within allowed directories.",
inputSchema: zodToJsonSchema(ListDirectoryArgsSchema) as ToolInput,
},@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.
Earlier quoted context omitted.
Or, in short: it's (an attempt to create) a standard protocol to plug tools to LLM app via the good ol' tools/function calling mechanism. It's not introducing new capabilities, just solving the NxM problem, hopefully leading to more tools being written. (At least that's how I understand this. Am I far off?)
We definitely hope this will solve the NxM problem. On tools specifically, we went back and forth about whether the other primitives of MCP ultimately just reduce to tool use, but ultimately concluded that separate concepts of "prompts" and "resources" are extremely useful to express different _intentions_ for server functionality. They all have a part to play!
I would love to integrate this into my platform of tools for AI models, Toolhouse [1], but I would love to understand the adoption of this protocol, especially as it seems to only work with one foundational model. [1] https://toolhouse.AI
This looks pretty awesome. Would love to chat with you if you are open about possible collab. I am frank [at] glama.ai
Earlier quoted context omitted.
We definitely hope this will solve the NxM problem. On tools specifically, we went back and forth about whether the other primitives of MCP ultimately just reduce to tool use, but ultimately concluded that separate concepts of "prompts" and "resources" are extremely useful to express different _intentions_ for server functionality. They all have a part to play!
Seems more accurate to state this reshapes the NxM problem rather than solving it.
Earlier quoted context omitted.
Here's a useful one that I wrote: https://github.com/anaisbetts/mcp-youtube Claude doesn't support YouTube summaries. I thought that was annoying! So I added it myself, instead of having to hope Anthropic would do it
Thanks. Added to https://glama.ai/blog/2024-11-25-model-context-protocol-quic...
Earlier quoted context omitted.
Seems more accurate to state this reshapes the NxM problem rather than solving it.
Yeah even I don't understand how it exactly solves the NXM problem (which translates to having M different prompts for N different llms. corerct me if I'm wrong please)
The N×M problem may simply be moved rather than solved:
- Instead of N×M direct integrations
- We now have N MCP client implementations
- M MCP server implementations