Does MCP support RAG?

[gsabran]

Pre-submission Checklist

• I have verified that this discussion would not be more appropriate as an issue in a specific repository
• I have searched existing discussions to avoid duplicates

Discussion Topic

I've been having a hard time understanding how RAG is supposed to work with MCP. My best guess is that a server that facilitates RAG would expose one resource template like

{
  "uriTemplate": "file:///rag/query{?input,maxResults,relevanceThreshold}",
  "name": "RAG endpoint",
  "description": "returns the most relevant contextual documents given the `input` parameter",
  "mimeType": "text"
}

Is this how one would do RAG through MCP? I didn't see any reference to RAG in the documentation. I would have expected to find some given that

MCP is an open protocol that standardizes how applications provide context to LLMs

[hichana]

One opportunity is if you have a tool call fetch data from an API endpoint you are building out. Then you could do RAG there and return data, which the LLM should then use for inference.

[jspahrsummers]

Yes, RAG could be represented either through resource templates or tools. MCP can also be useful to standardize RAG ingest in addition to retrieval.

We haven't yet felt the need for any specific RAG-related features in the spec or SDKs, but if you think some are necessary, we'd love to hear more.

[gsabran]

👍 I get that pretty much everything can be represented as a tool call, but that doesn't feel very idiomatic. Especially when prompts have their own API while they could similarly be a tool call.

Could you maybe share about the specific needs that have pushed you to elevate prompts and static resources to have specific APIs? That would be good context to understand if RAG is a similar or different category.

I have a chat client that relies on RAG to make better answers, which I think is very standard. I've been wondering how to represent this interaction through MCP.

MCP can also be useful to standardize RAG ingest 💯

[jspahrsummers]

Good question! We separated the key MCP primitives to model different "users" (is it the actual end user, the application, or the model?) as well as to represent different classes of data. Some discussion here: https://spec.modelcontextprotocol.io/specification/server/

It's definitely conceivable that RAG could justify a new primitive for similar reasons—just not sure what those are yet!

[gsabran]

Thanks, that model makes sense. It feels like RAG fits naturally within the "resources" category, but that the "list" then "get" pattern is not very idiomatic for this even though it can work.

[PederHP]

I think there's an argument for RAG to be supported, even if indirectly by some kind of context enrichment/transformation mechanism.

RAG is really context-dependent context. Could this be represented with a tool? Yes, but so could resources and prompts in principle.

So, I think if RAG is to be supported the best is through some kind of primitive that takes a context (message array?) and returns some kind of injection or mutation.

A delta would be most efficient but adds a lot of server complexity, so perhaps (context, additional_params) to (context_addition, hint) could work instead. It moves the complexity to the client.

This capability could facilitate RAG by providing a standard way to enrich context. It doesn't work for RAG that is post-inference but tools can already do that.

[PederHP]

This doesn't handle ingest, like document upload for a "talk to documents" style system. But I think that's good as it separates concerns more cleanly. Document upload could be facilitated by a resource upload mechanism instead. Integration of these two in a server should be trivial.

[jspahrsummers]

Would you be interested in opening a spec PR? We can discuss a concrete proposal there in the context of concrete client <> server messages.

[PederHP]

Sure thing.

[PederHP]

Would you be interested in opening a spec PR? We can discuss a concrete proposal there in the context of concrete client <> server messages.

Made a proposal here for a capability:
modelcontextprotocol/specification#142