NoteMesh

Here is a list of tools exposed by the MCP server to your LLM. There are many things you might want to do that combine these - for example, you might ask your LLM to find and attempt to fix broken links, which combines the vault health and editing tools. A full technical list of the tools is displayed in the settings for NoteMesh as well as here.

Reading your notes

• read_note — read any note, paging through long ones
• list_notes — list notes, optionally in one folder
• list_folders — see the vault's folder structure
• list_attachments — find images, PDFs, and audio in the vault
• read_attachment — view an image or pull down a file
• get_outline — a note's heading structure at a glance
• word_count — counts for one note or the whole vault
• random_note — surface something you'd forgotten

Writing and editing

• create_note — make a new note
• append_to_note — add to the end of a note (the safe one)
• prepend_to_note — add to the top, below the frontmatter
• update_note — replace a note's contents
• move_note — move or rename
• delete_note — delete, recoverable from sync or git history (can be turned off in the settings)
• unique_note — a timestamped Zettelkasten note

Daily notes

• daily_note — read or add to today's note, using your own Obsidian daily-note settings

Finding things

• search_vault — full-text search across every note, with snippets
• list_tags — every tag with how often it's used
• notes_by_tag — everything carrying a given tag
• read_properties — read frontmatter, or survey every property in the vault
• set_property / remove_property — edit frontmatter fields

Tasks

• list_tasks — every checkbox in the vault, or just what's open, or just today's
• toggle_task — tick one off

Links and vault health

• get_links — backlinks to a note, or its outgoing links
• list_link_issues — broken links, orphaned notes, dead ends
• get_vault_info — vault name, note count, word totals, sync status

1. You click this button and get a dedicated Railway server running your own copy of NoteMesh.
2. You go through a simple wizard to get set up. You'll set up an admin account for the server, add your Obsidian Sync account (recommended) or git setup, pick your vault, and the service will immediately start downloading and indexing your files.
3. Add the MCP URL as a custom connector to your LLM client (eg Claude Desktop, Claude Code, Codex, etc).
4. Start chatting!

Your data is safe on your own Railway server. The free account is really only usable for a trial. If you want 24/7 access you'll probably want at least a Hobby account.

1. You can either use a dedicated Railway server (recommended) or host it yourself by grabbing the bits from GitHub.
2. The Railway server is set up with all of the necessary hosting configuration out of the box, including the networking configuration to make it easy to (securely) access things from any device with an Internet connection.
3. The server uses SQLite to manage things like search, looking for content by tags or properties, etc. It uses either the Obsidian Sync headless CLI to manage the sync services, or a git daemon to watch your git repo, depending on the account type.
4. The data volume is used to store a copy of the data on the file system.
5. The recommended approach to using this with an LLM is OAuth, but in certain cases for some CLI LLM setups you might want to use an API key connection method instead.
6. The web app is a SolidStart based SPA that uses PicoCSS for styling.

Depending on your LLM client, you can point a chat at a local folder. A few disadvantages:

• You have to keep your computer on and connected to the Internet.
• You have to attach the folder again to new chats (varies depending on configuration).
• Direct folder access doesn't include the index or higher level tools.

The standard way I would expect most people to use this software is via a Railway app. If you use Railway, I'll get affiliate and template usage credit and you get your own private setup with inexpensive professional hosting.

The software itself is available via two licenses.

• The first is AGPL, the same open source license used by popular packages like Ghost (AGPL explained). For the vast majority of users, this is the open source license governing your usage.
• The second is a custom commercial license. This is primarily intended for hosting companies that might want to offer their own customized version for some reason. That's a relatively small group of folks. If you want a custom license you are welcome to reach out if you have questions.

In order to make sure everything is sorted properly, if you want to submit a patch you'll have to assign rights - so you'll need to agree to the contribution terms.

Obviously, security is critical for this project.

I've pointed multiple frontier LLMs as well as manually code reviewing everything. That said, (like any software) NoteMesh sits on a stack of software, and it's possible for any point in that stack to have a security issue.

I'll do my best to notify you if I find anything - but keep in mind that there is no built in update mechanism in the software itself. Railway does offer the option to get notifications, as well as alerts for things like disk usage (which I highly recommend setting up). Realistically, however, the best way to get notified is to sign up to the email list on this site. You can do that now, and you'll be reminded to do it during installation.

Below is a (partial) list of the security features. Despite all of my best efforts, keep in mind that you are using this software at your own risk.

Who can reach your notes

• OAuth 2.1 with PKCE — the same sign-in flow Claude and ChatGPT use for any connector; no password ever handed to the client
• Per-client access, individually revocable — disconnect one assistant from the dashboard without touching the others
• Every request re-checked against what that client was granted — a token that wasn't given write access is refused, not quietly allowed
• API keys as an alternative for clients whose OAuth support isn't there yet
• Nothing is public — every admin page and every vault operation requires a signed-in session or a valid token

Your credentials

• Obsidian and git credentials are encrypted at rest with AES-256-GCM
• The encryption key lives in your Railway environment, never in the database — someone holding a copy of the database file still can't read them
• The server refuses to start without a real 32-byte random key, so a weak one can't be used by accident
• Secrets are never passed as command-line arguments, so they don't show up in the process list
• Your vault password never leaves your server — it's used locally to talk to Obsidian Sync

Claiming the server

• A 30-minute claim window — if nobody claims the server in that time, the window closes rather than sitting open indefinitely
• Password recovery requires access to the server's own environment, plus a PIN that locks out after five wrong attempts and is compared in constant time

Keeping unwanted traffic out

• Rate limiting on failed sign-ins and on unauthenticated requests, so guessing is slow and floods are bounded
• Same-origin enforcement plus SameSite cookies — another site can't make your browser act on your server
• Request size limits, so an anonymous caller can't push large payloads at it
• The list of callable server functions is explicit — anything not on it is rejected, so nothing becomes reachable by accident
• Errors show a reference code, not internals — you can find the matching line in your logs; a stranger learns nothing

Staying inside your vault

• Every file path is resolved and confined to the vault folder — .. tricks are refused
• Symlinks can't be used to read outside it
• Invisible and direction-reversing Unicode characters are stripped from paths, a known trick for disguising a filename
• Size limits on what can be read in one call
• Attachment download links are cryptographically signed and expire in 15 minutes

The web app itself

• No CDNs, no web fonts, no analytics, no trackers — the admin interface loads nothing from anyone else, and a test fails the build if it ever does
• The build fails if server code leaks into the browser bundle

Deleting

• Deletes can be switched off entirely in Settings
• When on, they're recoverable — from Obsidian Sync version history or the previous git commit

Transparency

• Security-relevant events are written to an audit log you can read
• The full source is published under AGPL — nothing about this list has to be taken on faith
• A published security policy for reporting security issues

Prompt Injection

• Note content wrapped in per-session random markers. Tells the assistant that what's inside is data and not orders.
• NoteMesh has no tool that can send anything anywhere — no email, no web requests, no webhooks.

If you host it yourself you are going to have to make sure you set up the networking correctly to make sure your network security is set up correctly. If you are only using things on your own local network (for example, you set it up on your local UGreen NAS) it's probably fine, but if you expose things over the open Internet consider the following:

1. You'll either want a static IP or a correctly configured dynamic DNS setup.
2. You'll want to make sure you set up an HTTPS wrapper correctly (I highly discourage you from exposing an HTTP only connection over the public Internet).
3. Make sure you don't accidentally expose any other services or servers.

If you are technical enough to want to set this up yourself on your own servers (maybe you use a NAS with Docker support, like this nice UGreen model I personally use) - go for it. Just don't screw up your network punching a hole through the firewall (ahem).

If you read all of that and say to yourself, well, duh, then go forth and have fun. If you read any of that and either a) get kind of tired just thinking about it or b) find yourself saying WTF I highly recommend just saving yourself the hassle and sign up for the Railway server instead.