Logseq is built on the idea that notes are blocks, not documents. That is what makes it good, and it is also what makes connecting it to an AI assistant slightly more interesting than pointing a tool at a folder.
There are two ways to do it, they suit different people, and picking the wrong one is the reason most setups feel disappointing.
- No official server exists. Everything is community-built, discussed on the Logseq forum and subreddit.
- Two routes. The Logseq HTTP API for block-level access, or Filesystem MCP for the raw markdown.
- Filesystem is the easier start. No token, no API server, works with Logseq closed.
- The HTTP API is worth it if you need block references, queries and journal structure.
- Check your Logseq version first. File-based and database graphs do not behave the same way.
The two routes, and how to choose
Filesystem MCP
If you run the file-based version of Logseq, your graph is a folder of markdown files. Pages in one directory, journals in another, assets alongside them.
That means the standard Filesystem MCP server already does most of what you want. Point it at your graph directory and Claude can read every note, search across them, and write new ones. No Logseq plugin, no auth token, no API server to remember to start, and it works whether Logseq is open or closed.
The limitation is that Claude sees text files, not a graph. Logseq’s block references, page links and queries are markdown syntax to a filesystem reader. It can see ((block-ref)) sitting in a line. It cannot resolve what that block says.
For a lot of everyday use, that is completely fine. You are asking about the content of your notes, and the content is right there.
The Logseq HTTP API
Logseq ships an HTTP API server you can turn on under Settings, then Advanced, with Developer mode. Start it, copy the auth token, and MCP servers built against it get Logseq’s own model of your graph rather than a flat file view.
That means block-level operations. Reading a specific block and its children, following references properly, running Logseq queries, appending to today’s journal in the right place rather than at the end of a file.
The cost is that Logseq has to be running with the API server on, you are passing a token around your config, and you are depending on a community server keeping pace with Logseq’s changes.
- You mostly want to search and read your notes.
- You want it working in five minutes with no token.
- You want access whether or not Logseq is open.
- You already use Filesystem MCP for other folders.
- You need block references resolved, not shown as syntax.
- You want the assistant appending to journals correctly.
- You rely on Logseq queries and want those results.
- You are happy keeping Logseq running with the API on.
The servers worth knowing
ergut/mcp-logseq is the most frequently referenced option and works against the HTTP API. It is the one to try first if you have decided the API route is what you want.
joelhooks/logseq-mcp-tools and dailydaniel/logseq-mcp are the other two that come up regularly in the community listings. Similar goals, different design choices.
All are free and open source, none has a support desk, and the honest summary is that this ecosystem is smaller and less settled than Obsidian’s. That is worth knowing before you build a workflow that depends on it.
The file format catch
This is the thing to check before you spend an evening on setup.
Logseq’s long-running transition from a file-based graph to a database-backed one changes the assumption every filesystem approach rests on. If your graph is not a folder of markdown files, pointing Filesystem MCP at it does not do the thing you expect.
Servers built on the HTTP API are better positioned here, because they ask Logseq for data rather than reading its storage directly. But community servers move at community speed, and “works with the version I have” is a question worth answering by reading the server’s README rather than assuming.
The Logseq forum has active threads on exactly this. If you are running a database graph, search there before picking a server, because the answer changes faster than any blog post can keep up with, including this one.
What to actually ask
The daily journal is what makes Logseq different from a notes app, and it is where connecting an assistant pays off fastest.
- Mine your own journals. “What did I write about this project across all my daily notes?” Journals are where thinking gets recorded and never revisited. This is the query Logseq was built for and the one nobody runs.
- Find the thread. “Which of my notes connect to this idea, even if I did not link them?” A model spots semantic connections that your explicit links missed.
- Weekly review, automatically. “Summarize what I worked on in the last seven days of journals.” Two seconds instead of scrolling.
- Catch the loose ends. “Find TODO blocks I created more than a month ago and never closed.” Uncomfortable, useful.
- Write into the graph. “Add these three points to today’s journal under a Research heading.” The API route handles this properly. Filesystem will append text and get the nesting approximately right.
The pattern, as with any note graph, is that the assistant is best at the queries you would never run manually because the effort outweighed the answer.
The honest limits
The ecosystem is thin. Fewer servers, fewer maintainers, and more chance that the one you pick lags a Logseq release. Obsidian’s equivalent is significantly further along.
Filesystem access does not understand blocks. If your graph leans heavily on references and queries, a flat read will feel lossy, and that is a real gap rather than a configuration mistake.
Everything in one graph means everything is visible. Most people keep journals, work notes and personal thinking in a single graph. Connecting it connects all of that. Split anything sensitive into a separate graph you do not point the server at.
Large graphs get slow. Thousands of pages read through a filesystem server will not be instant. Scope the query when you can.
Where ContextBolt fits
Straight answer first. ContextBolt does not integrate with Logseq, and I would rather say that than imply otherwise.
What it does is the neighboring pile. Logseq holds what you wrote. ContextBolt holds what you saved, the threads from X, the Reddit posts, the LinkedIn ones, the articles you meant to come back to. It tags and clusters them automatically and ships its own MCP server, so Claude can search your saved reading the same way it searches your graph.
If you already went to the trouble of connecting Logseq to an assistant, the saved-links pile is the obvious next gap, because it is usually larger and almost always completely unstructured. Pro is $6 a month with a free tier to test on.
Your notes and your sources, both readable in one conversation. That is the setup worth building toward, and Logseq is a good half of it.
Worth doing?
Yes, and start with Filesystem MCP rather than the API.
It takes five minutes, needs no token, and tells you within an afternoon whether asking questions of your own graph is something you will actually do. If it sticks and you start wanting block references resolved properly, move up to the HTTP API then. Most people never need to.