mcp-raganything is not a RAG product
mcp-raganything wraps RAG-Anything as two MCP tools, index_corpus and ask_corpus. A socket for Claude, Codex, or Cursor. Not tenancy, rights, or production RAG.
mcp-raganything is an MCP server. You connect it to Claude, Codex, or Cursor. Two tools: index_corpus on a folder, ask_corpus on a question. That's the whole pitch.
It does not implement RAG. It wraps RAG-Anything, the HKUDS framework built on LightRAG, with MinerU for the parse. PDFs, Office, images, tables, equations. Under the hood: process_document_complete, then aquery in hybrid mode.
I like that for a local pile of documents. I would not put it behind a customer-facing agent and say the job is done.
Yohan already wrote the buy-vs-build note. RAG-Anything was the first standard brick we looked at. Cognee looked more finished for industrialisation: vectors, graph, MCP, S3. What was missing is a straight answer on mcp-raganything itself.
What mcp-raganything actually exposes
A thin socket:
- Recursively index a directory (PDF, DOCX, PPTX, XLSX, PNG, JPG, markdown)
- Ask the corpus. Hybrid vector plus graph, via LightRAG
- Persistent RAG instances per directory so you can query again without re-parsing everything
The agent sees two tools. RAG-Anything still does the parse and the graph. MCP is the socket. You still have to build everything around it.
That two-tool shape is the good version. Other community ports explode into insert, batch, extract entities, visualise the graph, clear the database. If you expose one tool per micro-operation, you burn tokens on schemas before anyone asks a real question. mcp-raganything stays at index_corpus and ask_corpus. Keep it that way.
Four jobs
People glue mcp-raganything into Claude, Codex, or Cursor and announce a knowledge base. At best they finished one of four jobs. Sometimes two.
| Job | mcp-raganything | What we actually ship |
|---|---|---|
| Parse messy files | MinerU inside RAG-Anything | A parser you chose on purpose. I standardise that step on Xberg when inventory and prose must not share a pipe. |
| Retrieve | LightRAG hybrid via ask_corpus | Vectors plus graph. Cognee-shaped if you need something closer to a product. |
| Talk to the model | Two MCP tools | MCP or an API. Few tools. Broad capability. |
| Who may see the doc | The machine running the client | Permissions, audit, tenant isolation. Still your problem. |
The implant catalog is the fence I actually care about: stocked sizes in tables, preference notes in chunks. A multimodal parser helps with the files. It does not invent that split.
When mcp-raganything is the right tool
Use it when the corpus lives on your disk and the only reader is you. A research folder, an internal PDF dump, equations and figures that naive chunking wrecks. Claude, Codex, or Cursor as the client, one user, one machine. If the index is wrong, you see it the same afternoon.
Fine as a lab. A bad way to serve other people's documents.
When it is not
Building the RAG is no longer the hard part. Cost, rights, observability. mcp-raganything does not touch any of that.
- Several people, several permission sets: the intern should not retrieve the board pack.
- Files in S3, not in
~/Documents. - You need traces: which chunk, which tool, which identity.
- You need a parse you can replay in CI, not just inside a local session.
MCP still makes sense when the agent talks to a custom API the model has never seen. That is a different job from "MCP everywhere." Indexing a folder for Claude, Codex, or Cursor is a private convenience. A retrieval API for documents that belong to someone else is a product.
What I would ship
RAG-Anything for multimodal parse and a LightRAG graph, on my machine. mcp-raganything only so the agent can index and ask. For other people: the fence, the rights, the traces, and a parser I trust when the files are ugly.
Keep the first two on your laptop if they help you read your own files. Do not ship the socket and call it the stack.