I use Joplin for both private notes and project docs that I share with AI coding assistants. The current tool toggles are helpful, but I’d also like per-note access levels:
Hidden — not visible to MCP clients
Title only — visible by title, but with no access to the body and no editing
Full access — subject to the existing tool permissions
These rules should also apply to search results and snippets, not just direct reads. Notebook-level defaults with per-note overrides would make this easier to manage.
It's unlikely we'll implement note level access control specifically for MCP, however with the upcoming note lock feature, you could lock the notes that you don't want MCP to access
My concern is that third-party servers may become less maintained now that there’s an official one. Would you consider a notebook exclusion list or name pattern instead of per-note permissions? That would cover my use case without needing full note-level access control.
Hmm, yes you're right we should probably have some way to restrict what can be accessed or not. But indeed an allow list is the way, rather than a deny one. Are you aware of any standard way to implement this in MCP servers?
You’re right that my setup is effectively a denylist. Default-deny would be safer, while an explicit * would still let users opt into broader access.
For a minimal UI, perhaps a text field with one notebook name or pattern per line. ! could mark exclusions, which would always take priority over allow patterns. An empty list, or a list containing only exclusions, would allow nothing.
These rules should apply across all tools, including search and direct access by note ID.
I think what would be useful too is a temporary allow per session - like a user might want to work on a group of note, or a notebook for just a session, but most of these times these notes (or all notes) should not be accessed.
Maybe using the MCP tools we even have the client to prompt for what notes should or should not be accessed
Temporary sessions (like you suggested) are a great idea, but the core rule should be that Joplin enforces the limits, not the AI client. You can't just prompt a model to stay out of a folder and expect it to comply. This also means there should be a quick way to enable or revoke a session in the Joplin UI, rather than hiding it deep in the settings -- perhaps a quick toggle next to the "Toggle AI Chat" button.
BTW, there is also a potential security hole right now: MCP and the Web Clipper appear to share the same token. If an AI agent gets that token, it might be able to bypass MCP restrictions and access the standard REST API directly. They really need separate credentials.
If we implement separate MCP tokens, each token could have its own notebook allowlist (default deny) — perhaps just a text area with one notebook name or pattern per line, and that's it, without much overengineering.
This solves the main problem: I could create one token for a local LLM with broad access, and a restricted token for cloud models that only sees specific project folders. As long as the allowlist is enforced server-side across all operations (search, read, etc.), this provides a solid security boundary without requiring a massive UI rewrite (just the settings dialog).
Yes, and what I had in mind is a proper restriction enforced by the app, because it's true that it can' be any other way. Say there's a tool that allows accessing a specific note with a specific ID. The client prompts for access to one or more of these IDs, and only if you agree the app gives access to these specific notes. At the app level we have a list of ID so we can deny anything else.
I don't know however if such a tool is currently possible within the MCP standard.