What happens when an LLM searches my memory

In the last post I explained that MCP gives the language model access to Obsidian.

But access alone doesn’t mean the model receives the entire vault.

When I ask a question about a project, the system works differently.

First the LLM decides which tool it needs.

For example, if it has to understand the current state of a project, it may start by searching the relevant area of Obsidian.

After that MCP returns not the whole project but a list of matching files and fragments.

And only then does the model open the documents actually needed for the answer.

In simplified form the chain looks like this:

question

search within the project

files found

reading the needed documents

assembling context

answer

For me this is a fundamental part of the architecture.

If the vault holds hundreds of projects and thousands of files, handing them all to the model is pointless.

Most of the information has nothing to do with the current question and only adds noise.

So the model moves through memory step by step.

For example, the real search-first protocol inside my MCP setup looks roughly like this:

searchInPath: Projects/Systems/PRJ-002 Network

query: internet OR VPN OR DNS OR MacStudio OR “Mac Studio” OR “MacBook Air” OR route OR routing OR split

First the search area is set.

Then, with one query, the system tries to get a wide enough set of candidates.

After that only the most relevant files are read.

This approach didn’t appear just to save context.

At some point I ran into the Obsidian MCP rate limit.

If the model starts guessing file names and making many sequential requests, the server may return 429 and temporarily stop further access.

So a separate principle appeared in the project:

search first, read later.

Don’t guess files one by one.

Don’t read the whole project in advance.

Don’t keep sending requests after a 429.

Find the area, run one wide search, and choose sources from the result.

Technically the MCP client itself also works through a sequence of separate operations.

First an MCP session is created.

Then the client gets the list of available tools.

After that the model can call a specific tool and pass it parameters.

In simplified form:

initialize

mcp-session-id

tools/list

tools/call

So MCP is not a channel through which all of Obsidian constantly flows into the LLM.

It’s more like a set of doors into project memory.

The model decides which door to open, gets a small piece of information and moves on if needed.

That’s exactly why this approach turned out to be more convenient for me than loading documents into the chat by hand.

I can ask about a project I haven’t touched for weeks, and the model will find its current state, read the right sources and rebuild the context from real files.

But so far we’ve only talked about the logic of access.

There’s one more question: how does a remote LLM even call an MCP server that physically runs on my Mac?

In the next post I’ll go through the whole path of a request, from the external model to the local Obsidian.