Turn a Local LLM Into a Semantic File Search Tool on Windows 11 With MCP

Human memory is associative and conceptual; traditional desktop search is relentlessly literal. In a personal experiment published by XDA Developers on October 15, 2026, writer Nolen Jonker detailed how connecting a locally hosted large language model (LLM) to personal directories via the Model Context Protocol (MCP) turned an everyday 8GB graphics card into a conversational file finder that outperformed standard Windows Search for meaning-based queries.

While one writer's daily workflow is not a controlled laboratory benchmark across millions of enterprise files, the setup highlights a compelling shift for Windows 11 users—especially those whose desktop processors lack the Neural Processing Unit (NPU) required for Microsoft's official Copilot+ semantic search. By bridging local AI runners with standardized filesystem tools, PC enthusiasts are building their own meaning-based retrieval systems without handing their folders over to the cloud.

How the Local LLM Filesystem Setup Works​

Unlike traditional Retrieval-Augmented Generation (RAG) pipelines that require chunking documents into a dedicated vector database ahead of time, the workflow described by Jonker relies on live tool calling through the Model Context Protocol (MCP). MCP is an open standard that allows a host application to grant an AI model structured access to external tools and local resources.

In this configuration, the backbone is the official @modelcontextprotocol/server-filesystem package, a Node.js server published on npm and documented in the Model Context Protocol GitHub repository. Because it runs via the npx package runner, having Node.js installed on the Windows machine is a prerequisite. The server is declared in the model runner's JSON configuration file by passing the package name and the target directory path:

"filesystem": {
  "command": "npx",
  "args": [
    "-y",
    "@modelcontextprotocol/server-filesystem",
    "YOUR DIRECTORY"
  ]
}

Note that according to the official MCP filesystem server documentation on GitHub, Windows environments sometimes require wrapping the npx call with cmd /c inside the JSON arguments (setting "command": "cmd" and "args": ["/c", "npx", "-y", "@modelcontextprotocol/server-filesystem", "C:\\path\\to\\dir"]) depending on how the host application spawns child processes.

Jonker reported running this configuration inside LM Studio, which stores its tool definitions in an mcp.json file accessible via the .lmstudio folder in the user directory or through the application's right-hand Program sidebar under the Install section. Other popular local AI clients handle the same JSON block in their own ways: AnythingLLM uses an anythingllm_mcp_servers.json file, while Jan exposes an MCP Servers menu once experimental features are toggled on.

What the Filesystem Server Can Actually Do​

When a user asks the local model a question, the LLM does not magically absorb the entire hard drive into its context window at once. Instead, the MCP filesystem server exposes specific programmatic tools to the model. According to the official MCP server documentation on GitHub, those tools are annotated with capability hints that separate pure reads from file modifications:

Section Summary: By pairing a local LLM runner like LM Studio with the Node.js @modelcontextprotocol/server-filesystem package, a model can actively browse directory trees, match file names, and open text files to inspect their contents in real time.

Why Standard Windows Search Often Misses the Mark​

To understand why a local language model feels so different in day-to-day use, it helps to look at how Windows 11 actually indexes and retrieves files. According to Microsoft Support documentation on search indexing in Windows, the operating system offers two primary indexing scopes under Settings > Privacy & security > Searching Windows:

• Classic mode: Indexes only the Documents, Pictures, Music, and Desktop folders by default to balance search speed with background resource usage.
• Enhanced mode: Expands the index across the entire PC and all user folders, consuming more disk space and background CPU cycles during updates.

Furthermore, Windows breaks file indexing down into two tiers under Advanced indexing options > File Types: Properties only (which captures metadata like file names and paths) and Properties and File Contents (which indexes the full text inside supported documents). If a file lives outside an indexed folder in Classic mode, File Explorer only checks filenames unless the user manually enables content searching in Folder Options—a setting that forces Windows to crawl through files one by one during the search. And as many Windows 11 users have noticed, typing a query into the Start menu frequently blends local file hits with Bing web results unless web search integration is disabled.

The Copilot+ NPU Divide​

Microsoft is well aware that users remember concepts better than exact strings. To solve this, Microsoft introduced semantic indexing alongside traditional lexical (keyword) indexing. According to Microsoft Support and Microsoft Learn developer documentation, semantic search allows queries like "pasta" to surface documents or images containing "lasagna," or a search for "car" to match "automobile" and "sedan." Microsoft also notes that all semantic index data is stored locally on the PC and is never used to train AI models.

However, there is a strict hardware gate: Microsoft Learn specifies that local semantic index queries (IncludeLocalSemanticIndex) require Windows 11 version 24H2 or later running on a Copilot+ PC (which mandates a dedicated NPU capable of 40+ TOPS) or an AI-enabled Windows 365 Cloud PC. On standard desktops and laptops without a qualifying NPU—such as Jonker's desktop powered by an Intel Core i7-13700F—Windows silently ignores semantic matching and falls back to traditional keyword lookup. Even on qualifying hardware, semantic matching is currently optimized for six core languages (English, French, German, Spanish, Japanese, and Simplified Chinese).

Ironically, millions of non-Copilot+ desktops sitting in home offices and gaming setups lack an NPU but house discrete graphics cards with 8GB, 12GB, or 16GB of VRAM—hardware that Microsoft's OS-level semantic indexer ignores, yet is more than capable of running compact local models like Google's Gemma family.

Section Summary: While Windows 11 supports fast keyword and content indexing, its concept-aware semantic search is locked behind Copilot+ NPU hardware requirements, leaving standard desktop GPUs untapped by built-in OS search.

Real-World Retrieval: Keyword Matching vs. Model Reasoning​

In Jonker's side-by-side testing using the Gemma E4B model inside LM Studio against standard Windows Search, the practical difference came down to how the two systems handle vague or synonymous prompts:

1. The Synonym Problem ("Night Theme" vs. "Dark Mode"): Searching the Windows Start menu for "night theme" returned Pinterest boards and Microsoft Edge add-ons. When the local LLM ran its initial filename search via MCP, it also came up empty—but because it could inspect the folder listing, it recognized a file titled "dark mode audit" as conceptually identical and surfaced it immediately.
2. Concept and Question Answering: When asked which note explained why people freeze up when given too many options, Windows Search matched the literal phrase "too many options" inside an unrelated onboarding note. The LLM located a "cognitive load summary" document, read the text via its MCP tool, and directly explained the passage regarding working memory overload.
3. Disambiguating Noisy Terms: A search for "subscription" in Windows surfaced a Windows Settings page and dozens of "subscription" folders buried inside old software development projects. The LLM bypassed the code directories and pulled up the user's pricing card note.

The Trade-Offs and Limitations​

Before anyone disables the Windows Search indexer, it is critical to view this workflow with a clear-eyed engineering lens. An MCP-connected LLM is a retrieval-and-reasoning agent, not a pre-built inverted index. That architecture brings real limitations:

• Latency vs. Instant Indexing: Once Windows builds its index (which takes up roughly 10% of the size of the indexed files, according to Microsoft Support), keyword lookups take a fraction of a second. A local LLM running on an 8GB GPU must process tool calls, list directories, read candidate files into its context window, and generate tokens. It is noticeably slower.
• UI Friction: You cannot double-click a file inside a standard LM Studio chat response to launch it in its native app. You have to look at the tool-call log to see which file path the model read and paste that path into File Explorer.
• Scale and File Format Boundaries: The official MCP filesystem server's read_text_file tool reads files strictly as UTF-8 text. While that works wonderfully for Markdown notes (.md), plain text (.txt), JSON, and source code, it will not natively parse complex binary office formats like .docx or .pdf without additional conversion tools or dedicated RAG parsers. Furthermore, if a directory holds thousands of files with cryptic names (like notes_1.txt through notes_5000.txt), the LLM cannot realistically read all of them on the fly during a single chat prompt.

Section Summary: Local LLM search excels at navigating curated folders of text notes where you remember the idea rather than the phrasing, trading the instant speed and click-to-open convenience of Windows Search for semantic reasoning.

Security, Privacy, and How to Configure It Safely​

Handing an AI model access to your local storage is not the same thing as typing a query into a passive search bar. As documented in the MCP filesystem specification, @modelcontextprotocol/server-filesystem includes destructive tools—specifically write_file, edit_file, and move_file—which can overwrite data in place or relocate files if the model hallucinates a command or misinterprets a prompt.

If you want to test this workflow on your own Windows 11 machine, follow these strict security practices:

1. Scope Your Directory Narrowly: Never pass C:\ or your entire user profile as the root argument when testing. Create or select a specific, non-sensitive folder (such as C:\Users\YourName\Documents\Notes) and pass only that path in mcp.json.
2. Enforce Read-Only Approvals: In your MCP client (such as LM Studio), configure tool permissions so that read-only operations (list_directory, read_text_file, search_files) are auto-approved, while write-capable operations (write_file, edit_file, move_file, create_directory) require explicit manual confirmation every time.
3. Verify Allowed Roots: Once your server is running, ask the model to invoke the list_allowed_directories tool first. Confirm that the server's active scope matches the exact folder you intended to expose.
4. Keep Sensitive Files Out of Reach: Even when running a local model offline, MCP servers are external Node.js processes. Only install official MCP packages from trusted repositories, and never point an experimental model runner at directories containing SSH keys, browser profiles, password vaults, or confidential enterprise records.

For Windows power users sitting on capable GPUs, the Model Context Protocol offers a fascinating glimpse into how desktop computing is evolving. You do not need to buy a brand-new NPU-equipped laptop just to ask your computer a plain-English question about your own notes—you just need a well-scoped JSON config, a local model, and a few extra seconds of patience.