261–270 of 283 posts
the docs aren't super clear yet wrt. how one might actually implement the connection. do we need to implement another set of tools to provide to the API and then have that tool call the MCP server? maybe i'm missing something here?
@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…
(forgive me if you know this and are asking a different question, but:)
I don't know how familiar you are with LLMs, but "context" used in that context generally has the pretty clear meaning of "the blob of text you give in between (the text of) the system prompt and (the text of) the user prompt"[1], which acts as context for the user's request (hence the name). Very often this is the conversation history in chatbot-style LLMs, but it can include stuff like the content of text files you're working with, or search/function results.
[1] If you want to be pedantic, technically each instance of "text" should say "tokens" there, and the maximum "context" length includes the length of both prompts.
@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!
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 and I have been working on this for the last few months at Anthropic. I am happy to answer any questions people might have.
MCP: I've gotten 2,415 times smarter since then.
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!
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 illustr…
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.
Earlier quoted context omitted.
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…
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.
- 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