Note Search via an MCP Server: Chunking to Fit Model Limits and Caching

⚡ The gist in 5 seconds - Local semantic search over meeting notes is implemented as an MCP server: you can search by meaning rather than by an exact word. - Note text is split into chunks sized to the model's context limit, and search results are cached. - This is a personal project with a write-up on Habr: no version numbers, builds, or public releases are involved here. ### 🔍 What was found Habr has published a first-person write-up (article 1090934) on local semantic search across a folder of call summaries and meeting transcripts. The original problem is described as follows: plain keyword search doesn't work, because in your head the query sounds like "hiring," while the file says "interview" and other wording. The solution is to set up search as an MCP server — that is, to expose semantic search over notes as a tool that an LLM client can connect to. MCP (Model Context Protocol) is a protocol through which LLM-based clients hook up external tools and data. Judging by the title, the author examines two technical challenges of this kind of search. The first is chunking documents so that each fragment fits within the model's limit: meeting notes are longer than the window that can be fed in a single pass, so the text has to be split into parts and indexed separately. The second is caching: to avoid recomputing the same thing and running the model again on identical queries. The original description doesn't mention specific model names, embedding dimensions, or chunking parameters — the full breakdown is in the article itself. ### 💡 Why it matters Semantic search over personal notes is a classic pain point: meeting notes can't be found by keywords because the wording in the file doesn't match the wording in the query. Wrapping it in an MCP server turns such a DIY project from a standalone script into a tool that plugs into any compatible LLM client — and it's part of a broader wave: MCP is becoming the standard way to expose local data and utilities to a model. The practical benefit here is that search stays local, while the two most expensive parts — tokens for a long document and repeated queries — are handled by chunking and caching. There's no talk of anything landing in a stable release on any timeline: this is an account of a personal implementation, not a product with versions and dates.

🔗 Read on habr.com