SoloMD: a local-first Markdown editor with a bundled MCP server for Claude Code and Cursor

What SoloMD is for, and who it is actually aimed at

SoloMD is an editor for people whose notes are already a folder of Markdown files. The README's framing is blunt: your notes live in a folder, and SoloMD is the editor on top, with an agent surface inside the editor and an MCP endpoint that Claude Code or Cursor can drive from outside. The target user is not someone looking for a note-taking system to migrate into. It is someone who has a vault on disk and wants two things to touch it: their own hands, and an LLM.

The second audience is narrower and more interesting. The bundled `solomd-mcp` server runs against any folder of Markdown files, and the README states you do not need to install SoloMD itself to drive your vault from Claude, Cursor, Cline or Continue. That means the MCP server is usable as a standalone component by people who never open the editor. For an engineer wiring an MCP client into a documentation repo, that is the part worth evaluating, not the WYSIWYG editing.

What it is not: a collaborative workspace. There is no SoloMD-hosted server, no subscription, and the README says AI keys, embeddings index and git history stay on your machine. That is a design commitment, and it also sets the ceiling on what the product can do.

How the editor and the MCP server share one vault

The architecture visible in the repository is a Tauri 2 desktop app with a Vue 3 front end and CodeMirror 6 as the editing surface. The MCP server is a separate Rust crate at `mcp-server/`, with a development harness at `dev-mcp/`. That split matters: the server is not a plugin loaded into the app process, it is a binary that takes a workspace path and speaks MCP over stdio.

The data flow is one-directional in the sense that matters. Both the editor and the MCP server read and write the same `.md` files on disk. There is no SoloMD database in the middle and no network port, which the README states explicitly for the agent CLI path. The LLM only sees what you point the workspace at, and path traversal is guarded.

The knowledge-graph layer added in 4.6 is where the design gets opinionated. Frontmatter properties are edited through a properties inspector (`⌘⇧I`) that performs line-surgical writes, preserving comments, inline arrays and quoting byte-for-byte. Typed relationships (`belongs_to`, `related_to`, `has`) resolve automatic inverses server-side for large vaults. Saved filtered views are persisted as `.solomd/views/*.yml`. That is a real file format on disk, not app state, which is consistent with the local-first claim.

One thing the README does not describe is conflict handling when the editor and an agent write the same file. It documents git history staying local, but not a merge or lock story.

Installing SoloMD and pointing an MCP client at a vault

The README gives several install paths. On macOS there is a Homebrew cask, a direct dmg download, and a shell installer. On Windows there is an MSI, a portable zip, a PowerShell installer, and a winget package. Linux ships AppImage, deb and rpm builds for x86_64 and aarch64, plus a `solomd-bin` package on AUR. The iPad build is on the App Store. The macOS cask is the shortest path:

brew install --cask zhitongblog/solomd/solomd

After installing, the first real use is not writing a note. It is connecting a client. The README documents a command that prints the MCP configuration snippet for your AI client:

solomd mcp-config

According to the README, that prints something shaped like this, with the workspace path pointing at your vault:

{
  "mcpServers": {
    "solomd": {
      "command": "/Applications/SoloMD.app/Contents/Resources/solomd-mcp",
      "args": ["--workspace", "/Users/me/Documents/SoloMD"]
    }
  }
}

Paste that into Claude Desktop, Cursor or another MCP client. For more than one vault, the README says to repeat `--workspace`:

"args": [
  "--workspace", "/Users/me/Documents/SoloMD",
  "--workspace", "/Users/me/Documents/work-notes"
]

There is also a direct CLI path that hands a prompt to the `claude` or `codex` CLI:

solomd agent "rewrite this week of dailies into a weekly review and commit it"

The README states this path is path-traversal guarded and opens no network port. It does not document what the agent CLI does if the target file changed on disk between the read and the write.

Where SoloMD is the wrong tool

The clearest limitation is platform support at the bottom of the range. The README is direct about Windows 7, 8 and 8.1: they cannot be supported, because the Rust toolchain requires Windows 10 since Rust 1.78 and Microsoft froze WebView2 at version 109 on Windows 7 with no security updates. There is no legacy build. If you are maintaining machines on those versions, this project is closed to you, and the README says so rather than leaving it ambiguous.

A second limit is the plugin surface. The README describes a built-in feature set (KaTeX, Mermaid, Vim mode, Hunspell plus CJK proofread, semantic search, wikilinks, slideshow mode, tldraw whiteboards) but does not describe a third-party plugin API. If your workflow depends on extending the editor with community plugins, SoloMD is not a drop-in substitute for an editor that has one.

A third is that the knowledge-graph features assume conventions. Typed relationships only resolve if your frontmatter uses the documented keys. Saved views live in `.solomd/views/*.yml`. Notes that do not follow those conventions simply will not appear in the type-driven sidebar, which is a reasonable design but a migration cost for an existing vault.

Finally, the README does not document rollback for agent edits. If an MCP client rewrites a file badly, recovery depends on the git history the README says stays on your machine, not on any undo the editor provides for external writes.

SoloMD compared with Typora and Obsidian

The README itself links a comparison page against Obsidian, Typora and Tolaria, which tells you where the maintainer expects the question to come from. The difference in approach is worth stating plainly.

Typora is a WYSIWYG Markdown editor and little else. SoloMD's editing surface is in the same family (the README describes it as Typora-style live edit), but the product is not just the editor. The MCP server, the agent CLI, and the frontmatter relationship graph are the parts Typora does not attempt. If you only want to write Markdown and never hand a file to an LLM, the extra surface is weight you will not use.

Obsidian is the closer comparison because both are local-first and both work on a folder of Markdown. The structural difference the README draws is that SoloMD's agent surface is first-class inside the editor and exposed as an MCP endpoint, while Obsidian's extension model is plugins. Obsidian has the larger ecosystem; SoloMD has the MCP server shipped in the box rather than added. The README claims format cross-compatibility with Tolaria for tldraw whiteboards stored in a ` ```tldraw ` fence, which suggests the maintainer is deliberately keeping on-disk formats portable rather than proprietary.

For a team already standardized on Obsidian, the switching cost is the frontmatter conventions and the loss of plugins, not the file format.

Maintenance, build cost and what the MIT licence means here

The repository is not archived, and the last push was on 2026-08-29, which is recent enough to treat the project as currently being worked on. The release cadence visible in the repository is tight: v4.11.17 on 2026-08-23, v4.11.19 on 2026-08-27, and v4.11.20 on 2026-08-29. There is a single maintainer, and the README points to GitHub Discussions for async contact plus Telegram and WeChat for real-time chat.

Building from source is a pnpm and Tauri workflow in the `app/` directory:

git clone https://github.com/zhitongblog/solomd.git
cd solomd/app
pnpm install
pnpm tauri dev      # dev with hot reload
pnpm tauri build    # release artifacts → src-tauri/target/release/bundle/

On Linux the README notes an extra system dependency, `libdbus-1-dev`, for the keychain backend. End-to-end testing runs through `scripts/v4-self-test.sh`, with `--with-release --with-ollama --with-ui` for full coverage. That is a real cost if you intend to fork rather than consume releases: a Rust toolchain, Node, pnpm, and platform-specific system libraries.

The licence is MIT, copyright 2026 xiangdong li. MIT is permissive, so forking and internal redistribution are straightforward, but the practical implication here is different: the app bundles no AI provider and the README describes BYOK across 14 providers. Your API keys stay in your own keychain, which means the licence question and the data-residency question are separate. This is not legal advice; check the LICENSE file and your own provider terms.

Editorial conclusion

Adopt SoloMD if you already keep notes as plain .md files in one folder and you want an MCP client to edit that same folder without a sync service in the middle. Skip it if you need a plugin ecosystem, a hosted sync backend, or a team permission model, because the README describes none of those. Before committing, run `solomd mcp-config`, check that the printed `--workspace` path is the vault you intend to expose, and confirm your client connects; the README does not document a rollback path for agent edits, so test on a copy of the vault first.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes