How the LLM got access to my Obsidian

Once I had separated project memory from execution, the next problem appeared.

Obsidian already held all the information I needed about my projects: architecture, implementation plans, technical passports, decision history, Canvas and related documents.

But the language model couldn’t see that memory.

Until I pasted the right file into the chat myself, it effectively didn’t exist for the model.

I could have searched for implementation_plan.md by hand every time, copied the right notes, added related documents and explained where the project currently stood.

But then the very idea of project memory loses much of its point.

I needed access to the real Obsidian, not yet another copy of its contents inside a chat.

That’s how MCP entered the system.

In my case the MCP server works as an interface between the language model and Obsidian.

It gives the model a set of concrete tools: view a project’s structure, find a note, search the vault, read a file, or edit an ordinary note on direct request.

The whole of Obsidian is not loaded into the model.

The LLM only gets tools through which it can reach the information it needs on its own.

For example, if I ask what’s happening in a particular project, there’s no need to hand the model the whole project in advance.

It can find it, open implementation_plan.md, turn to decisions_log.md or other related documents if needed, and only then form an answer.

Technically there’s one more layer between the model and the files.

The MCP server talks to Obsidian through the Local REST API, and Obsidian itself works with the real vault on my Mac.

So the chain looks like this:

LLM

MCP server

Obsidian Local REST API

Obsidian vault

What matters to me here is the principle.

Project memory stays in files and remains the source of truth.

The LLM doesn’t keep a separate copy of the project’s state and doesn’t need me to assemble context for it by hand every time.

It gets the ability to turn to memory when that memory is actually needed.

It was after this that Obsidian finally stopped being just a place where notes sit.

It became working memory that language models and other tools can connect to through a formal interface.

Today this MCP setup remains my main way of giving an LLM access to Obsidian.

But the tool call itself hides quite a lot of interesting mechanics.

In the next post I’ll go through what actually happens when an LLM looks for something in my memory: how it chooses a tool, how the request passes through MCP, and why the model doesn’t get the whole vault as one big context.