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!