joplin-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| JOPLIN_READONLY | No | Set to 'true' to enable read-only lock mode. Any value other than 'false', '0', 'no', 'off', or empty string will enable lock mode. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| execute_joplin_readonly_scriptA | Execute JS with global 'joplin' object in read-only mode. Top-level await. Return the result. Modifications, deletions, and creations are blocked. NOTEBOOKS (read-only): listNotebooks(fields?, orderBy?, orderDir?, limit?) getNotebook(id) getNotebookNotes(notebookId, fields?, orderBy?, orderDir?, limit?) getNotebookTree(notebookId, depth?) — formatted tree getAllNotebooksTree({ exclude? }) — notebooks only, respects scope getScopedTree({ exclude?, depth? }) — notebooks + notes, respects scope NOTES (read-only): listAllNotes(fields?, includeDeleted?, orderBy?, orderDir?, limit?) searchNotes(query) — returns note array readNote(id) — formatted display with metadata + line numbers getNote(id) — raw object getNoteLineRange(id, startLine, endLine) searchInNote(id, pattern) getNoteSections(id) Call as joplin.notebooks.X() or joplin.notes.X(). SEARCH: searchNotes("any:1 term1 term2"). Use OR/synonyms, not user's literal phrase. Syntax: "any:1", "tag:X", "notebook:X", "title:X", "updated:month-1", "type:todo", "iscompleted:0", "docker*", "-excluded". RULES:
|
| execute_joplin_scriptA | Execute JS with global 'joplin' object with write/destructive permissions. Top-level await. Return the result. Supports all read-only methods, search syntax, and call patterns defined in 'execute_joplin_readonly_script', plus the following modifying/destructive methods: NOTES (write/destructive): createNote(title, body, notebookId?, tags?, isTodo?, todoDue?, todoCompleted?) updateNote(id, { title?, body?, parent_id?, is_todo?, todo_due?, todo_completed? }) appendToNote(id, content) prependToNote(id, content) deleteNote(id) moveNoteToNotebook(noteId, notebookId) editNote(id, oldString, newString, replaceAll?) RULES:
|
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 2 tools
The two tools have nearly identical names and both execute JavaScript, differing only in permissions (read-only vs. write). The descriptions are detailed enough to distinguish them, but the overlap in core functionality could cause initial confusion for an agent.
Both tool names follow a consistent 'execute_joplin_<permission>_script' pattern, using snake_case and clear permission labels (readonly vs. script). No mixing of conventions.
Only 2 tools for a server that exposes a full API (CRUD for notebooks, notes, search, etc.) feels minimal. While the design intentionally wraps everything into two script executors, a more granular tool surface might be expected given the scope.
All operations available through the Joplin API are accessible via the two tools (read-only in one, write in the other). No obvious gaps in functionality; the set fully covers the domain.