What can you do with this server?

This server lets AI assistants read, search, create, update, and delete notes in Apple Notes on macOS. Key capabilities include: * List Folders — Retrieve all Apple Notes folders with their note counts. * List Notes — Browse notes sorted by most recently modified (limit 1–200, default 25), optionally filtered by folder. * Search Notes — Case-insensitive search across note titles and/or bodies, with configurable result limits and scope (all or title only). * Read a Note — Fetch full note content by ID or exact title, with a configurable character limit (default 10,000 chars) to avoid flooding context. * Create a Note — Add a new note with a title and plain-text or HTML body, optionally placed in a specific folder. * Update a Note — Modify an existing note by replacing or appending to its body, and optionally rename it. * Delete a Note — Move a note to "Recently Deleted" (recoverable for ~30 days) by ID or exact title.

Which integrations are available for this server?

Provides tools for reading, searching, and creating notes in Apple Notes on macOS.

How do I use apple-notes-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@apple-notes-mcp Show my 10 most recent notes" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

apple-notes-mcp

by simantaturja

Overview Schema Related Servers Score Discussions

TypeScript

Local

apple-notes-mcp

npm version npm downloads license platform: macOS

An MCP (Model Context Protocol) server that lets AI assistants like Claude read, search, and create notes in Apple Notes on macOS.

Published on npm as @simantaturja/apple-notes-mcp — no clone or build needed, your MCP client runs it via npx.

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

Related MCP server: Apple Notes MCP Server

Setup

No clone, no build. Your MCP client downloads and runs the server on demand via npx.

Claude Code

claude mcp add apple-notes -- npx -y @simantaturja/apple-notes-mcp

Claude Desktop

Add to ~/Library/Application Support/Claude/claude_desktop_config.json:

{
  "mcpServers": {
    "apple-notes": {
      "command": "npx",
      "args": ["-y", "@simantaturja/apple-notes-mcp"]
    }
  }
}

Restart your client. The first call pulls the package from npm (cached afterward) — see Automation permission for the one-time macOS prompt.

Install from source

For development or to run a local build instead of the published package:

git clone https://github.com/simantaturja/apple-notes-mcp.git
cd apple-notes-mcp
npm install   # builds automatically via the `prepare` hook

Then point your client at the built entry, e.g. for Claude Code:

claude mcp add apple-notes -- node /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": "npx",
      "args": ["-y", "@simantaturja/apple-notes-mcp"],
      "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 under System 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/resolver snippets (evaluated directly in Node), and cache invalidation with an injected fetcher — so they need no macOS automation permission and run in ~250 ms.

The integration test drives the built server over real JSON-RPC and exercises create → 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 it creates 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_note moves 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 (pass folder: "Recently Deleted" to list them explicitly). Note: the folder is matched by name (default Recently Deleted); on a non-English macOS locale, set APPLE_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 to Notes.app costing tens of milliseconds. A naive loop over notes pays notes × properties round trips. This server instead fetches each property for all notes 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 stay in 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 each note's modificationDate — so a cache entry self-invalidates the moment a note changes, and deletes are evicted automatically. Each search after the first only re-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 results are always current — unlike index-based servers that serve stale results between re-indexing runs.

3. No index, no embeddings, no warm-up. RAG-based servers (LanceDB + embedding models) need a ~200 MB model download, an initial indexing pass over every note, and re-indexing when notes change — and can serve stale results between re-indexes. This server queries Notes.app live: zero setup, 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 when Apple changes the schema. JXA is the supported automation interface.

Fit guidance: designed for libraries up to a few thousand notes. The cold-cache search grows with library size (one bulk body fetch); warm searches stay flat. At many thousands of large notes, an indexed/semantic-search server will answer the first 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 on every call. Both are kept deliberately small:

Lean schema — 7 tools ≈ 1,050 tokens total (~150/tool). Feature-heavy servers ship 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 as idPrefix with short per-note ids (p634). All tools accept either form.
Bounded responses — get_note caps bodies at max_chars (default 10,000 chars ≈ 2,500 tokens) with a truncation marker telling the model exactly how to fetch the rest. A single huge note can never flood the context.
No noise — empty folder fields omitted, dates without milliseconds, plaintext bodies (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 for just 5 notes before these optimizations (~47% reduction at equal content).

License

MIT

Available Tools

7 tools

create_noteA

Create a new note in Apple Notes. Body accepts plain text (line breaks preserved) or HTML.

ParametersJSON Schema

Name	Required	Description
`title`	Yes	Note title
`body`	No	Note body — plain text or HTML
`folder`	No	Folder to create the note in (default: the default Notes folder)

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description partially covers behavior: it mentions body accepts plain text or HTML with line breaks preserved. However, it omits other behaviors like folder creation behavior or title constraints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, front-loaded with purpose, no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple creation tool with 3 parameters and no output schema, the description covers key aspects (creation, body format). Missing details like folder behavior or limits, but overall adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds the clarification that body accepts plain text or HTML with line breaks preserved, which provides nuance beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (create) and resource (new note in Apple Notes), and distinguishes from siblings like delete_note, get_note, etc by specifying creation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives (e.g., update_note). Implied usage is clear but lacks exclusions or context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

delete_noteA

Delete an Apple Note. The note is moved to Recently Deleted (recoverable for ~30 days), not permanently erased. Locate by id (preferred) or exact title.

ParametersJSON Schema

Name	Required	Description	Default
`id`	No	Note id from list_notes/search_notes (short or full)
`title`	No	Exact note title (used if id not given)

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description discloses the key behavioral trait: deletion is soft (moved to Recently Deleted, recoverable for ~30 days). This is valuable but doesn't cover all potential side effects or permissions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with no filler. The first sentence defines the action and behavior, the second gives parameter guidance. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (2 parameters, no output schema, no nested objects), the description adequately covers purpose, behavior, and parameter usage. No missing information for an agent to use it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already describes both parameters (100% coverage). The description adds extra semantic value by indicating preference ('preferred') and condition ('exact title'), going beyond schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (Delete) and the resource (Apple Note), and specifies that the note is moved to Recently Deleted, distinguishing it from other operations like update or create.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides guidance on how to locate the note: 'by id (preferred) or exact title', indicating a preference and correctness condition. However, it does not explicitly state when to use this tool versus alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_noteA

Read the full content of an Apple Note by its id (preferred, from list_notes/search_notes) or exact title.

ParametersJSON Schema

Name	Required	Description
`id`	No	Note id from list_notes/search_notes (short, e.g. 'p634', or full x-coredata URL)
`title`	No	Exact note title (used if id not given)
`max_chars`	No	Max body characters to return (default 10000); raise for long notes

TDQS

A4.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It states the read behavior and max_chars limit, but does not mention return format, error handling, or permissions. Partial transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, no filler, front-loaded with verb and resource. Efficient and clear.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read tool with 3 parameters and no output schema, the description covers access methods and character limit. Lacks explicit output format or error conditions, but is adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description adds context: id is preferred from specific tools, and max_chars can be raised for long notes. This adds value beyond the schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool reads the full content of an Apple Note, specifying two access methods (by id or exact title). It distinguishes from sibling tools like list_notes (which lists) and search_notes (which searches).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description indicates the preferred parameter (id from list_notes/search_notes) and provides an alternative (title). It implicitly guides when to use each, but does not explicitly state when not to use this tool or compare to other tools like update_note.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_foldersA

List all folders in Apple Notes with their note counts.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.1/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must cover behavior. It states it returns note counts, which is useful, but lacks details on pagination, rate limits, or permissions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence with no redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only list tool with no output schema, the description provides sufficient information: it lists all folders with note counts.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist, and schema coverage is 100%. The description does not need to add parameter info; baseline is 4 for zero-parameter tools.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'list' and resource 'folders', and adds 'with their note counts', which distinguishes it from sibling tools that operate on notes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit usage guidelines are provided, but the sibling tool names (create_note, delete_note, etc.) imply this tool is for folders, not notes. However, no when-not or alternative use cases are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_notesA

List notes in Apple Notes, most recently modified first. Optionally filter by folder name. Returns id, title, folder, and modification date.

ParametersJSON Schema

Name	Required	Description	Default
`folder`	No	Folder name to list notes from (e.g. 'Notes', 'Work')
`limit`	No	Maximum number of notes to return (default 25)

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses ordering and return fields. No annotations, but description adds behavioral context (read-only implied). Could mention that limit controls pagination.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no redundancy, front-loaded with purpose. Efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema, but description covers return fields and ordering. Could mention limit behavior and default value explicitly, but sufficient for simple list.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so description's mention of optional folder filter adds little beyond schema. Baseline 3 adequate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states verb 'list', resource 'notes', ordering by modification date, optional folder filter, and return fields. Distinguishes from siblings like search_notes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implies usage for listing notes with optional folder filter, but lacks explicit guidance on when to use this versus search_notes or other siblings. No exclusion criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_notesA

Search Apple Notes by text in the note title or body. Returns matching notes (id, title, folder, modification date).

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	Text to search for (case-insensitive)
`limit`	No	Maximum number of results (default 20)
`scope`	No	'all' searches titles and bodies; 'title' searches titles only (faster)	all

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description carries full burden. It discloses the read-only nature and return fields, which is sufficient. However, it could mention that searches are case-insensitive (in schema) or that no modifications occur.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences: first states purpose, second states output. Very concise, front-loaded, no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the essential purpose and return fields. It lacks only minor details like ordering or pagination behavior, which are partially handled by the schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds high-level context but does not provide additional details beyond the schema parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool searches Apple Notes by text in title or body and lists the return fields. It effectively distinguishes from siblings like get_note (by ID) and list_notes (all notes without search).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for text-based search but does not explicitly state when to use this tool versus alternatives like get_note or list_notes. No when-not or alternative guidance is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

update_noteA

Update an Apple Note: replace its body or append to it. Locate by id (preferred) or exact title.

ParametersJSON Schema

Name	Required	Description	Default
`id`	No	Note id from list_notes/search_notes (short or full)
`title`	No	Exact note title (used if id not given)
`body`	Yes	Content to write — plain text or HTML
`mode`	No	'replace' the whole body, or 'append' to the end	replace
`new_title`	No	Rename the note (replace mode only)

TDQS

A3.7/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must disclose behavioral traits. It only mentions the two update modes but does not cover authentication requirements, idempotency, error conditions, or any side effects beyond the mentioned behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no redundancy. The verb and resource are front-loaded, making the purpose immediately clear.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 5 parameters, no output schema, and no annotations, the description is adequate but leaves gaps: no mention of return value, error behavior, or prerequisites (e.g., note existence). It covers the core function but not the full context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema descriptions cover 100% of parameters. The description adds clarity on how to locate notes ('by id (preferred) or exact title') and the two update modes, providing value beyond the schema's individual parameter descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Update') and resource ('Apple Note'), and distinguishes between 'replace' and 'append' modes. It clearly states how to locate the note, differentiating it from siblings like create_note or get_note.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is for modifying existing notes but does not explicitly state when to use it vs alternatives like create_note or delete_note. No when-not-to-use or exclusion criteria are provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.2/5.0

Disambiguation5/5

Each tool has a distinct purpose: CRUD operations for notes, listing/searching notes, and listing folders. No functional overlap.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern in snake_case (e.g., create_note, list_folders, search_notes). No deviations.

Tool Count5/5

7 tools is appropriate for an Apple Notes MCP server, covering all essential operations without unnecessary redundancy.

Completeness4/5

Covers full CRUD for notes, search, and folder listing. Minor gap: no tool to create or rename folders, but core note workflows are complete.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

notesbridge
io.github.IsaiahDupree
Search, read, and write your Apple Notes from ChatGPT/Claude via a local Mac agent + MCP relay.
Note Taking App Automation
1
xNotepad AI
com.xnotepadai
Create, search, and update notes in an xNotepad AI notebook, with semantic search and AI Q&A.
Note Taking AI & Machine Learning Knowledge & Memory
1
local-mcp A
com.local-mcp
Let ChatGPT, Claude & Cursor use your Mac: email, calendar, iMessage, Teams, files. Local, free.
Email Calendar Management File Systems
2033
Mem
io.github.mem-labs
Securely search, create, and organize your Mem notes and collections from AI assistants.
Knowledge & Memory Search
1

Related MCP Servers

Apple Notes MCP Server
Note Taking OS Automation App Automation
arslankhanali
F
license
A
quality
D
maintenance
Enables interaction with Apple Notes on macOS through AppleScript, allowing users to list, search, read, create, update, and delete notes across accounts and folders.
Updated 9 months ago (2025-12-03 01:22 UTC)
7
1
Apple Notes MCP Server
Note Taking Knowledge & Memory
RodriguesJohn
A
license
A
quality
D
maintenance
Enables AI assistants to read, create, search, update, and delete Apple Notes through natural language conversation, using JXA to communicate directly with the Notes app.
Updated 5 months ago (2026-03-20 17:57 UTC)
8
433
27
MIT
Apple Notes MCP
Note Taking Workplace & Productivity
taylorarndt
A
license
A
quality
D
maintenance
Enables AI clients to search, read, create, update, move, and delete Apple Notes on macOS via AppleScript automation.
Updated 2 months ago (2026-07-18 15:42 UTC)
10
433
2
MIT
simplenote-mcpofficial
Note Taking Search
Automattic
A
license
Not graded
quality
C
maintenance
Enables AI tools to read and optionally write Simplenote notes via local database or API, supporting offline use on macOS.
Updated a month ago (2026-07-27 18:42 UTC)
503
21
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/simantaturja/apple-notes-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

apple-notes-mcp

Requirements

Setup

Claude Code

Claude Desktop

Install from source

Environment variables

Automation permission

Tools

Example prompts

Notes on create_note

Development

Project layout

Tests

Security

Why it's fast

Why it consumes few tokens

License

Available Tools

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

simplenote-mcpofficial

Latest Blog Posts

MCP directory API

Notes on `create_note`