Summary
Uploading files into Claude Projects or ChatGPT, building RAG on a vector database, or giving the AI a full-text index of the file server as MCP tools: how the three approaches differ on exact codes and numbers, folder structure, freshness, permissions and effort, and when each one is the right choice.
TL;DR: For a few documents that rarely change, uploading them into the chat or a project is the simplest thing that works. For questions answered by prose (policies, manuals, knowledge articles) where users phrase things differently from the text, RAG with embeddings is strong. For a company file server, where people look for an article number, a customer name, a drawing, the newest version of a list, in thousands of files that change every day and not everyone may see, a full-text index exposed as tools, which is what AnythingMCP File Search is, fits better. They are not exclusive; many teams end up with more than one.
Three ways to give an AI your documents
1. Upload into the chat or a project. You add files to a conversation or to a project's knowledge in Claude or ChatGPT. The provider keeps a copy and decides how the model gets at it: small sets go into the context whole, larger ones are typically retrieved in parts. Nothing to run, nothing to maintain, but the copy is only as current as your last upload.
2. Retrieval-augmented generation (RAG) on a vector database. A pipeline cuts every document into chunks, turns each chunk into an embedding, and stores them in a vector database. At question time the question is embedded too, the most similar chunks are retrieved and handed to the model. It is the standard architecture behind most "knowledge base" products and many in-house projects.
3. A full-text index, exposed as tools (AnythingMCP File Search). AnythingMCP indexes the file names and the text of every page of a folder on a NAS, file server, SFTP, WebDAV or S3 source, keeps it in sync, and gives the AI client MCP tools: search by content, find by name, list a folder, exact search for codes, read pages, get the file. The model decides which tool to call, the way a colleague would first look in the right folder and then open the file.
Side by side
| Upload into chat or project | RAG on a vector database | File Search (full-text index + MCP tools) | |
|---|---|---|---|
| Where the files stay | Copy at the AI provider | Copy of the text in your vector database | On your server or NAS; the index holds the text |
| Keeping current | Re-upload by hand | Your ingestion pipeline | Automatic sync; only changed files are read |
Exact codes and numbers (AD-24004, DIN 18101) | Depends on how the provider retrieves | Weak spot: similar codes look alike to embeddings | Literal search, Excel rows with their column names |
| Questions phrased differently from the text | Good while everything fits in context | Strong: retrieval by meaning | Depends on the model trying the right words and synonyms |
| Folder structure, file names, dates | Mostly lost | Kept only if you store them as metadata | First-class: every hit has its folder, file and date; "newest first" is a filter |
| Thousands of files | Limited by plan and context | Yes | Yes, within the plan's file limit |
| Who sees what | Whoever is in the project | You build it | MCP roles, one connector per folder, folder permissions per role (Enterprise) |
| Sources in the answer | Often | If you build it | File, page and date on every hit, and the file itself on request |
| Which AI client | That provider's app | Your app | Every client with remote MCP: Claude, ChatGPT, Copilot, Gemini, Cursor |
| Effort | None | A project: chunking, embeddings, pipeline, evaluation | A wizard: connect, scan, describe, activate |
Where each one is the right choice
Upload when the set is small, stable and personal: a contract you are negotiating, three manuals for a project, a paper you are reading. There is no infrastructure, and the model sees exactly what you gave it.
Build RAG when the content is prose, the questions are open ("what is our policy on…", "how do I…"), users do not know the terms the documents use, and you have someone to own the pipeline and its quality. Retrieval by meaning finds the paragraph about "returns after 30 days" when the user asks about "sending something back late".
Use File Search when the knowledge is a file server that people already organise in folders: price lists, data sheets, drawings, offers, saved e-mails, Excel exports. Questions there are mostly about a specific thing (a number, a name, a file, the latest version), the answer has to be exact and sourced, the folder changes daily, and not everyone may see everything. File Search is also the option that keeps the files where they are, works across AI clients, and needs no pipeline.
The honest trade-offs of File Search
- No embeddings. File Search does not rank by semantic similarity. The model compensates by trying several words and synonyms, the tools give it snippets and dates to choose from, and the connector's description tells it the vocabulary of the folder; but a question phrased very differently from the text is the case vector search handles better.
- It needs a text layer. Scanned PDFs without text are found by name only, unless you are on Enterprise with OCR. Images and CAD files are found by name.
- Plan limits. The number of indexed files is part of the plan (500, 2,000, up to 50,000 on Cloud Enterprise, unlimited self-hosted Enterprise). Select the folders people actually ask about.
- Tool calls take turns. The assistant searches, then reads. That is a few seconds per question, in exchange for answers that cite the page.
Why exact matters on a file server
Ask an embedding-based system for the price of AD-24004 and it retrieves the chunks most similar to the question. In a price list, the rows for AD-24004, AD-24040 and AD-24004-G are nearly identical in meaning, and the 2025 list is as similar to the question as the 2026 list. Similarity is the wrong measure for an identifier. A literal search either finds AD-24004 or it does not, and every hit carries its file date, so the model can take the current list and say which one it used. See Find an article number in PDF and Excel price lists for the full walkthrough.
Can you combine them?
Yes. File Search is one connector among others on an AnythingMCP server. A team can keep a RAG-based knowledge base for its policies, connect the file server through File Search, and add the ERP and CRM as further connectors; the AI client sees all of them as tools and picks per question. Uploading a document into a chat for a one-off question still works next to all of it.
FAQ
Is File Search a RAG system? In the broad sense that the model retrieves text before it answers, yes. In the usual narrow sense (chunks, embeddings, vector database), no: it is a full-text index with page-level results, and the retrieval is done by the model through tools.
Do my files go to the AI provider with File Search? Only what a tool returns for a question: a list of matches, the text of a page, a link. With a self-hosted AnythingMCP the index stays on your server.
What about Google Drive, OneDrive or SharePoint? Cloud drives have their own connectors (in AnythingMCP's catalog, and in Claude and ChatGPT) that search through the drive's API. File Search is for the places without such an API: a NAS, a Windows share, an SFTP or WebDAV server, an S3 bucket.
Related
- Search your company file server with AI
- Search a Synology or QNAP NAS with Claude and ChatGPT, step by step
- Find an article number in PDF and Excel price lists
- Find technical drawings by part number with AI
- Search an e-mail archive of .msg and .eml files with AI
- Folder permissions per role for AI file search
- What is MCP?
Was this guide helpful?
