apple-notes-mcp
An MCP (Model Context Protocol) server that lets AI assistants like Claude read, search, and create notes in Apple Notes on macOS.
It talks to Notes.app via JXA (JavaScript for Automation) through osascript — no private APIs, no database hacks, and it works with iCloud-synced notes.
Requirements
- macOS (tested on macOS 14+)
- Node.js >= 18
- Apple Notes.app
Installation
git clone https://github.com/simantaturja/apple-notes-mcp.git
cd apple-notes-mcp
npm install # builds automatically via the `prepare` hook
Setup
Claude Code
claude mcp add apple-notes -- node /absolute/path/to/apple-notes-mcp/dist/index.js
Claude Desktop
Add to ~/Library/Application Support/Claude/claude_desktop_config.json:
{
"mcpServers": {
"apple-notes": {
"command": "node",
"args": ["/absolute/path/to/apple-notes-mcp/dist/index.js"]
}
}
}
Environment variables
| Variable | Default | Purpose |
|---|---|---|
APPLE_NOTES_TRASH_FOLDER |
Recently Deleted |
Name of the special trash folder. macOS localizes this name; set it to your locale's name (e.g. Nylig slettet on Norwegian) so deleted notes are correctly excluded from list_notes/search_notes. |
Set it in your MCP client config, e.g. for Claude Desktop:
{
"mcpServers": {
"apple-notes": {
"command": "node",
"args": ["/absolute/path/to/apple-notes-mcp/dist/index.js"],
"env": { "APPLE_NOTES_TRASH_FOLDER": "Nylig slettet" }
}
}
}
Automation permission
The first time a tool runs, macOS will prompt:
"node" wants access to control "Notes".
Click Allow. If you accidentally denied it, re-enable underSystem Settings → Privacy & Security → Automation.
Tools
| Tool | Description |
|---|---|
list_folders |
List all folders with note counts |
list_notes |
List notes (most recently modified first), optionally filtered by folder. Params: folder?, limit (1–200, default 25) |
search_notes |
Case-insensitive search in note titles and bodies. Params: query, limit (1–100, default 20), scope (all|title, default all) |
get_note |
Read a note's content by id (short or full, preferred) or exact title. Param max_chars (default 10000) truncates long bodies |
create_note |
Create a note. Params: title, body (plain text or HTML), folder? |
update_note |
Replace or append to a note's body, optionally rename. Params: id/title, body, mode (replace|append, default replace), new_title? |
delete_note |
Delete a note (moved to Recently Deleted, recoverable ~30 days). Params: id/title |
Example prompts
- "List my Apple Notes folders"
- "Show my 10 most recent notes"
- "Search my notes for 'tax return'"
- "Read the note titled 'Meeting agenda'"
- "Create a note called 'Groceries' with milk, eggs, bread in the Shopping folder"
- "Add 'butter' to my Groceries note"
- "Delete the note titled 'Old draft'"
Notes on create_note
- Plain-text bodies are HTML-escaped and line breaks are preserved.
- If the body starts with
<, it is treated as raw HTML (Notes bodies are HTML). Notes.app sanitizes what it stores, but only pass HTML you trust. Bear in mind the body usually comes from the AI model, so treat it as untrusted: a prompt-injected model could emit arbitrary HTML here. Plain-text bodies are always escaped, so this only applies to bodies you (or the model) deliberately start with<. - The title is rendered as the note's first line (
<h1>), which Notes uses as the note name.
Development
npm run dev # tsc --watch
npm start # run the built server (stdio transport)
Project layout
src/
index.ts entry point — wires transport, registers tools
jxa.ts runs JXA scripts via osascript (argv-safe)
snippets.ts shared JXA code (HTML escaping, note resolution, folder map)
helpers.ts result wrappers, id-prefix factoring, body truncation
cache.ts in-process plaintext + folder-map caches
types.ts NoteSummary / NoteDetail
tools/read.ts list_folders, list_notes, search_notes, get_note
tools/write.ts create_note, update_note, delete_note
test/ node:test suites (see below)
Tests
npm test # fast unit tests — no Notes.app, no permissions needed
npm run test:integration # full lifecycle against real Notes.app (creates + deletes a test note)
Unit tests run pure logic — id factoring, body truncation, the JXA HTML/resolversnippets (evaluated directly in Node), and cache invalidation with an injectedfetcher — so they need no macOS automation permission and run in ~250 ms.
The integration test drives the built server over real JSON-RPC and exercisescreate → search → update → get → delete. It is opt-in (gated on APPLE_NOTES_IT=1,set by the script) because it touches your real Notes library; the test note itcreates is deleted (moved to Recently Deleted) at the end.
You can also smoke-test by piping JSON-RPC to the server:
echo '{"jsonrpc":"2.0","id":1,"method":"tools/list"}' | node dist/index.js
Security
- User input is passed to JXA via
argv, never interpolated into the script — no script injection. - Scripts run through
execFile(no shell), with a 120s timeout and bounded output buffer. - Note titles and plain-text bodies are HTML-escaped before being written to Notes.
delete_notemoves notes to Recently Deleted (recoverable for ~30 days) — it never permanently erases.- Title-based update/delete refuses to act when multiple notes share the title (use
id). - Notes in Recently Deleted are excluded from
list_notes/search_notes(passfolder: "Recently Deleted"to list them explicitly). Note: the folder is matched by name (defaultRecently Deleted); on a non-English macOS locale, setAPPLE_NOTES_TRASH_FOLDER(see Environment variables) so the exclusion applies. - Everything runs locally; no note content leaves your machine except through the MCP client you connect.
Why it's fast
All numbers below measured on a real library (436 notes, 28 folders, Apple Silicon).
1. Bulk Apple Events instead of per-note calls.Every JXA property access (note.name()) is one Apple Event — an IPC round trip toNotes.app costing tens of milliseconds. A naive loop over notes paysnotes × properties round trips. This server instead fetches each property for allnotes in a single event (Notes.notes.name() returns every name at once):
| Approach | Measured |
|---|---|
| Naive per-note loop, 25 notes | 1,784 ms |
| Bulk fetch, all 436 notes | 47 ms |
Per note that is roughly 650× faster, and it's why end-to-end tool calls stayin the 300–550 ms range including Node and osascript process startup.
2. Incremental plaintext cache.Note bodies are cached in-process, keyed by note id and validated against eachnote's modificationDate — so a cache entry self-invalidates the moment a notechanges, and deletes are evicted automatically. Each search after the first onlyre-fetches notes that actually changed:
| Search | Measured |
|---|---|
| First search of a session (cold cache) | ~430 ms |
| Every following search (warm cache) | ~180 ms |
Title-only search (scope: "title") |
~160 ms |
There is no staleness window: metadata is checked live on every call, so resultsare always current — unlike index-based servers that serve stale results betweenre-indexing runs.
3. No index, no embeddings, no warm-up.RAG-based servers (LanceDB + embedding models) need a ~200 MB model download, aninitial indexing pass over every note, and re-indexing when notes change — and canserve stale results between re-indexes. This server queries Notes.app live: zerosetup, zero warm-up, never stale.
4. Minimal runtime.Two runtime dependencies (MCP SDK, zod). No Bun, no transformers, no vector DB.Server is up and answering in ~125 ms.
5. No Full Disk Access / SQLite parsing.Servers that read the Notes SQLite database need Full Disk Access and break whenApple changes the schema. JXA is the supported automation interface.
Fit guidance: designed for libraries up to a few thousand notes. The cold-cachesearch grows with library size (one bulk body fetch); warm searches stay flat. Atmany thousands of large notes, an indexed/semantic-search server will answer thefirst search faster — in exchange for the indexing machinery above.
Why it consumes few tokens
Tool schemas load into the model's context every session; tool results enter it onevery call. Both are kept deliberately small:
- Lean schema — 7 tools ≈ 1,050 tokens total (~150/tool). Feature-heavy serversship 15–20+ tools and several times that on every single session.
- Compact JSON — no pretty-printing (~18% smaller).
- Factored id prefix — note ids share a 55-char
x-coredata://UUID/ICNote/prefix; list/search return it once asidPrefixwith short per-note ids (p634).All tools accept either form. - Bounded responses —
get_notecaps bodies atmax_chars(default 10,000chars ≈ 2,500 tokens) with a truncation marker telling the model exactly how tofetch the rest. A single huge note can never flood the context. - No noise — empty folder fields omitted, dates without milliseconds, plaintextbodies (never raw HTML, which some servers return at 3–10× the token cost).
Measured: list_notes of 25 notes ≈ 2,150 chars (~540 tokens) — versus 925 chars forjust 5 notes before these optimizations (~47% reduction at equal content).
License
MIT