5 ms·

Thank you. That’s good feedback. The gist of it is: you have an llm application such as Claude desktop. You want to have it interact (read or write) with some

Thank you. That’s good feedback. The gist of it is: you have an llm application such as Claude desktop. You want to have it interact (read or write) with some system you have. MCP solves this. For example you can give the application the database schema as a “resource”, effectively saying; here is a bunch of text, do whatever you want with it during my chat with the llm. Or you can give the application a tool such as query my database. Now the model itself can decide when it wants to query (usually because you said: hey tell me what’s in the accounts table or something similar). It’s “bring the things you care about” to any llm application with an mcp client

TeMPOraL 2y ago
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?)
- jspahrsummers 2y ago
  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!
  - zestyping 2y ago
    I think this where the real question is for me. When I read about MCP, the topmost question in my mind is "Why isn't this just tool calling?" I had difficulty finding an answer to this. Below, you have someone else asking "Why not just use GraphQL?" And so on. It would probably be helpful for many of your readers if you had a focused document that addressed specifically that motivating question, together with illustrated examples. What does MCP provide, and what does it intend to solve, that a tool calling interface or RPC protocol can't?
    - jspahrsummers 2y ago
      You can find more information on some design questions like these in https://spec.modelcontextprotocol.io/specification https://spec.modelcontextprotocol.io/specification, which is a much more "implementors" focused guide than the user documentation at https://modelcontextprotocol.io https://modelcontextprotocol.io
  - ramoz 2y ago
    Seems more accurate to state this reshapes the NxM problem rather than solving it.
    - mayank_agarwal 2y ago
      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)
      - ramoz 2y ago
        N (LLM clients/vendors) x M (tools/tool suppliers). 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 This feels similar to SOAP but might be more of a lower level protocol similar to HTTP itself. Hard to tell with the implementation examples being pretty subjective programs in python.
worldsayshi 2y ago
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.
- threecheese 2y ago
  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, for example to request something from the hosts LLM. - A client sits in the middle, representing the human in the loop. It manages the requests bidirectionally It seems mostly modeled around the security boundaries, rather than just AI capabilities domains. The client is always in the loop, the host and server do not directly communicate.
  - worldsayshi 2y ago
    I look at the filesystem server and I don't see any indication of a difference between a tool that is just reading from one that is doing changes: https://github.com/modelcontextprotocol/servers/blob/main/src/filesystem/index.ts 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, },
shenbomo 2y ago
Great work on the protocol!! I am looking for some examples of creating my own custom client with the Anthropic API leveraging MCP, but I could not find any. Pretty much want to understand how Claude Desktop is integrating with MCP Server along with Anthropic API Can you provide some pointers about the integration? e.g. import anthropic client = anthropic.Anthropic() response = client.messages.create( model="claude-3-5-sonnet-20241022", max_tokens=1024, [mcp_server]=... ## etc.? ... )

TeMPOraL 2y ago

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?)

jspahrsummers 2y ago
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!
- zestyping 2y ago
  I think this where the real question is for me. When I read about MCP, the topmost question in my mind is "Why isn't this just tool calling?" I had difficulty finding an answer to this. Below, you have someone else asking "Why not just use GraphQL?" And so on. It would probably be helpful for many of your readers if you had a focused document that addressed specifically that motivating question, together with illustrated examples. What does MCP provide, and what does it intend to solve, that a tool calling interface or RPC protocol can't?
  - jspahrsummers 2y ago
    You can find more information on some design questions like these in https://spec.modelcontextprotocol.io/specification https://spec.modelcontextprotocol.io/specification, which is a much more "implementors" focused guide than the user documentation at https://modelcontextprotocol.io https://modelcontextprotocol.io
- ramoz 2y ago
  Seems more accurate to state this reshapes the NxM problem rather than solving it.
  - mayank_agarwal 2y ago
    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)
    - ramoz 2y ago
      N (LLM clients/vendors) x M (tools/tool suppliers). 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 This feels similar to SOAP but might be more of a lower level protocol similar to HTTP itself. Hard to tell with the implementation examples being pretty subjective programs in python.

worldsayshi 2y ago

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.

threecheese 2y ago
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, for example to request something from the hosts LLM. - A client sits in the middle, representing the human in the loop. It manages the requests bidirectionally It seems mostly modeled around the security boundaries, rather than just AI capabilities domains. The client is always in the loop, the host and server do not directly communicate.
- worldsayshi 2y ago
  I look at the filesystem server and I don't see any indication of a difference between a tool that is just reading from one that is doing changes: https://github.com/modelcontextprotocol/servers/blob/main/src/filesystem/index.ts 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, },

shenbomo 2y ago

Great work on the protocol!! I am looking for some examples of creating my own custom client with the Anthropic API leveraging MCP, but I could not find any. Pretty much want to understand how Claude Desktop is integrating with MCP Server along with Anthropic API Can you provide some pointers about the integration? e.g. import anthropic client = anthropic.Anthropic() response = client.messages.create( model="claude-3-5-sonnet-20241022", max_tokens=1024, [mcp_server]=... ## etc.? ... )