Which integrations are available for this server?

Provides tools for interacting with Apple Notes on macOS, enabling AI agents to list accounts and folders, search, read, create, update, move, and delete notes programmatically through the Apple Notes application. Allows managing notes across different iCloud accounts, including listing iCloud accounts and folders, and moving notes between iCloud accounts with a copy-and-delete strategy to avoid native cross-store bugs.

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 Find my notes about the launch plan." 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 taylorarndt

Overview Schema Related Servers Score Discussions

TypeScript

Local

Apple Notes MCP

MIT License MCP macOS Apple Notes Node.js

I made this because I wanted Apple Notes to feel useful inside modern AI tools.

I use Apple Notes for real things: business meetings, planning, random ideas, credentials I should probably organize better, notes spread across different accounts, and all the half-remembered stuff where I later ask, "What was that thing I talked about in that meeting?"

There are already a lot of Apple Notes MCP servers. Some of them probably work fine. But the ones I tried did not feel like they were built for how I actually want to use AI: query my notes naturally, retrieve the right context, organize notes, create new notes, and move notes between accounts without making the AI fight the tool.

So this is my version of an Apple Notes MCP: simple, local, practical, and designed for AI clients like Codex, Claude, Cursor, and anything else that speaks MCP.

Quick Links

Related MCP server: Apple Notes MCP Server

What This Does

This MCP lets an AI client work with Apple Notes on your Mac.

You can ask things like:

"Find my notes about that business meeting."
"What did I write about the launch plan?"
"Create a note for this idea."
"Move this note from my personal iCloud account to my work account."
"Organize these notes into the right folders."
"Pull the full text of this note so we can use it as context."

The server can:

list Apple Notes accounts;
list folders;
search notes by title and plaintext body;
read full notes;
create notes;
update note title/body;
move notes between folders;
move notes across accounts;
delete notes with dry-run safety;
create folders.

Why This One

Apple Notes is good, but it was not designed as an AI knowledge base. MCP makes it possible to bridge that gap.

The goal here is not to be fancy. The goal is to be dependable:

Use Apple Notes through the supported macOS automation path.
Avoid directly reading or mutating the private Notes database.
Return stable IDs that AI clients can use for follow-up actions.
Default risky operations like move/delete to dry-run.
Handle cross-account moves in a way that avoids Apple Notes' native cross-store move bug.
Exclude Recently Deleted from normal search results so deleted notes do not look active.

Requirements

macOS with Apple Notes installed.
Node.js 20 or newer.
Apple Notes accounts already signed in on the Mac.
macOS Automation permission for whichever app launches the MCP server.

This server uses AppleScript automation. That is intentional. Apple does not provide a nice public Apple Notes API, and reading the private Notes database directly is fragile.

Install

Clone or open this project, then run:

cd /path/to/apple-notes-mcp
npm install
npm run build

For this local checkout, the path is:

cd /Users/taylorarndt/hq/developer/apple-notes-mcp
npm install
npm run build

Run Manually

npm start

Most people will not run it manually. Your MCP client will launch it for you.

MCP Configuration

Use the built dist/index.js file:

{
  "mcpServers": {
    "apple-notes": {
      "command": "node",
      "args": [
        "/Users/taylorarndt/hq/developer/apple-notes-mcp/dist/index.js"
      ]
    }
  }
}

Replace the path with wherever you installed the project.

Codex

Add the server to your Codex MCP config using the same command and args:

{
  "mcpServers": {
    "apple-notes": {
      "command": "node",
      "args": [
        "/Users/taylorarndt/hq/developer/apple-notes-mcp/dist/index.js"
      ]
    }
  }
}

Then restart Codex so it discovers the server.

Claude Desktop

Add this to your Claude Desktop MCP configuration:

{
  "mcpServers": {
    "apple-notes": {
      "command": "node",
      "args": [
        "/Users/taylorarndt/hq/developer/apple-notes-mcp/dist/index.js"
      ]
    }
  }
}

Restart Claude Desktop. The first time it tries to use Notes, macOS may ask for permission.

Claude Code

Use the same MCP server definition:

{
  "mcpServers": {
    "apple-notes": {
      "command": "node",
      "args": [
        "/Users/taylorarndt/hq/developer/apple-notes-mcp/dist/index.js"
      ]
    }
  }
}

If Claude Code cannot access Notes, check macOS Automation permissions for the terminal or app that launched it.

Cursor

In Cursor, add an MCP server with:

{
  "mcpServers": {
    "apple-notes": {
      "command": "node",
      "args": [
        "/Users/taylorarndt/hq/developer/apple-notes-mcp/dist/index.js"
      ]
    }
  }
}

Restart Cursor after adding it.

macOS Permissions

This part matters.

Apple Notes access is controlled by macOS Automation permissions. The app launching the server needs permission to control Notes.

If the server cannot access Notes:

Open System Settings.
Go to Privacy & Security.
Open Automation.
Find the app launching the MCP server.
Allow it to control Notes.

Depending on your setup, the app might be Claude Desktop, Cursor, Terminal, iTerm, Codex, or another MCP host.

You can test the underlying AppleScript access with:

osascript -e 'tell application id "com.apple.Notes" to get name of every account'

Then test the MCP bridge with:

npm run build
npm start

From an MCP client, call notes_status.

Tools

`notes_status`

Checks whether Apple Notes automation is available.

`notes_list_accounts`

Lists Apple Notes accounts available on the Mac.

`notes_list_folders`

Lists folders. You can filter by account name.

Arguments:

accountName optional exact account name.

`notes_search`

Searches note titles and plaintext bodies.

Arguments:

query optional search text.
accountName optional exact account name.
folderName optional exact folder name.
limit default 25, max 200.
includePlaintext default false.
includeBodyHtml default false.
includeRecentlyDeleted default false.

`notes_get`

Reads one full note.

Use noteId whenever possible. Titles are not unique.

Arguments:

noteId preferred stable note ID.
title exact title fallback.
accountName optional disambiguator.
folderName optional disambiguator.

`notes_create`

Creates a note in a target folder.

Arguments:

title required.
bodyHtml required.
accountName and folderName, or accountId and folderId.

`notes_update`

Updates a note title and/or body.

Arguments:

noteId preferred stable note ID.
currentTitle exact title fallback.
accountName optional disambiguator.
folderName optional disambiguator.
newTitle optional replacement title.
bodyHtml optional replacement body.

`notes_move`

Moves a note to another folder. This can be in the same account or a different account.

Arguments:

noteId preferred stable note ID.
title exact title fallback.
accountName optional source disambiguator.
folderName optional source disambiguator.
destinationAccountName optional.
destinationFolderName optional.
destinationAccountId optional.
destinationFolderId optional.
dryRun default true.

For cross-account moves, the returned note ID changes. Keep using the returned note.id.

`notes_delete`

Deletes a note. Defaults to dry-run.

Arguments:

noteId preferred stable note ID.
title exact title fallback.
accountName optional disambiguator.
folderName optional disambiguator.
dryRun default true.

`notes_create_folder`

Creates a folder in an Apple Notes account.

Arguments:

name required folder name.
accountName optional.
accountId optional.

Reliability Notes

Use IDs for anything important.

Titles and folder names are useful for humans, but they are not unique. A good AI workflow is:

Search notes.
Show or inspect the matches.
Use the returned noteId for read, update, move, or delete.

Move and delete default to dryRun: true. That is deliberate. It lets the AI resolve exactly what it is about to touch before it changes anything.

Cross-account moves do not use Apple Notes' native move operation. Native AppleScript moves across accounts can trigger a Core Data cross-store save error. This server handles cross-account moves with a copy-then-delete strategy and returns the new destination note ID.

Deleted notes go to Recently Deleted. Normal search excludes Recently Deleted by default so old deleted notes do not show up as active knowledge.

Tested Workflow

This has been tested end-to-end through the Node bridge used by MCP clients:

list accounts;
list folders;
create a note;
read the note;
search for the note;
update the note;
dry-run a move;
move the note across accounts;
verify the moved note's destination and content;
dry-run delete;
delete;
verify no active matching note remains.

Final test result:

{
  "ok": true,
  "created": "x-coredata://2D043C23-37C8-49EB-B30B-76080C224F76/ICNote/p460",
  "movedTo": "x-coredata://01C0A48D-207A-4C34-8F56-724B8CF4CACF/ICNote/p15",
  "finalActiveMatches": 0
}

Development

Build:

npm run build

Run:

npm start

The server uses stdio, which is what most MCP clients expect.

Available Tools

10 tools

notes_createA

Create a new Apple Note in a target folder. bodyHtml should be valid lightweight HTML such as div, p, ul, ol, li, h1-h3.

ParametersJSON Schema

Name	Required	Description
`title`	Yes	Note title.
`bodyHtml`	Yes	Note body as HTML.
`folderId`	No	Stable Apple Notes folder ID.
`accountId`	No	Stable Apple Notes account ID.
`folderName`	No	Destination folder name.
`accountName`	No	Destination account name, for example iCloud.

TDQS

A3.9/5.0

Behavior4/5

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

Annotations indicate readOnlyHint=false (modification), destructiveHint=false (not destructive), which match the creation action. Description adds a behavioral constraint: bodyHtml should be valid lightweight HTML (e.g., div, p, ul, ol, li, h1-h3), which is important for correct invocation.

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 provides critical formatting guidance. No redundant or irrelevant information. Efficient and front-loaded.

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?

Given 6 parameters (2 required) and no output schema, the description covers the core creation action and body format but lacks information on behavior when both folderId and folderName are provided, error conditions, or return value. Adequate but not comprehensive.

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 description coverage is 100%, so baseline is 3. Description adds value by clarifying acceptable HTML tags for bodyHtml, which is not in the schema description. However, no additional semantics are provided for other parameters like folderId or accountId.

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 action ('Create'), resource ('Apple Note'), and context ('in a target folder'). It also provides guidance on acceptable HTML in bodyHtml. This distinguishes it from sibling tools like notes_update or notes_delete.

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

Usage Guidelines2/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., notes_update for modifying existing notes). No mention of prerequisites or exclusions. The description only states the basic purpose, leaving the agent to infer usage context.

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

notes_create_folderB

Create a folder in an Apple Notes account.

ParametersJSON Schema

Name	Required	Description
`name`	Yes	New folder name.
`accountId`	No	Target account ID.
`accountName`	No	Target account name.

TDQS

B3.4/5.0

Behavior2/5

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

Annotations indicate mutation (readOnlyHint=false) and non-destructive creation (destructiveHint=false). The description adds nothing beyond 'create a folder,' failing to disclose any side effects, required permissions, or account 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?

A single, clear sentence with no redundant words. The purpose is front-loaded and entirely earned.

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 fully documented parameters and no output schema, the description is mostly adequate. However, it could benefit from mentioning relationships to sibling tools (e.g., listing folders after creation) to be fully complete.

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 all three parameters are documented. The description does not add extra meaning or format details beyond the schema, so a baseline score of 3 is appropriate.

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 'create' and the resource 'folder in an Apple Notes account.' It is specific and immediately distinguishes from sibling tools like notes_create, which creates a note.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives like notes_list_folders, nor when not to use it. The description lacks context for selection.

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

notes_deleteB

Destructive

Delete an Apple Note. Defaults to dryRun=true so clients can verify the resolved note before deletion.

ParametersJSON Schema

Name	Required	Description
`title`	No	Exact note title. Use with accountName/folderName when noteId is unknown.
`dryRun`	No	When true, resolve the note without deleting it.
`noteId`	No	Stable Apple Notes note ID. Prefer this over title.
`folderName`	No	Folder name used to disambiguate title lookup.
`accountName`	No	Account name used to disambiguate title lookup.

TDQS

B3.3/5.0

Behavior3/5

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

Annotations already indicate destructiveHint=true, and the description reaffirms deletion. It adds the dry-run safety mechanism but omits details on reversibility or cascading effects.

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

Conciseness4/5

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

Single sentence, efficient and to the point. Could front-load more, but no wasted words.

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

Completeness2/5

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

No output schema and description does not mention return values or confirmation of deletion. For a destructive tool with no output info, this is a gap.

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% with descriptions for all five parameters. The description does not add extra meaning beyond the schema, so baseline 3 applies.

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

Purpose4/5

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

The description clearly states 'Delete an Apple Note' with a specific verb and resource. It distinguishes from sibling tools by being the delete operation, but does not elaborate on deletion semantics.

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?

Mentions dryRun default for safe verification, implying a cautious usage pattern. No explicit when-not-to-use or alternatives, but the deletion context is clear.

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

notes_getB

Read-only

Read a full Apple Note, including plaintext and HTML body.

ParametersJSON Schema

Name	Required	Description
`title`	No	Exact note title. Use with accountName/folderName when noteId is unknown.
`noteId`	No	Stable Apple Notes note ID. Prefer this over title.
`folderName`	No	Folder name used to disambiguate title lookup.
`accountName`	No	Account name used to disambiguate title lookup.

TDQS

B3.4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false. Description adds that it returns plaintext and HTML body, but does not disclose error handling or behavior for missing notes. With annotations, the bar is lower, but only marginal additional context provided.

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 with no fluff, front-loaded with the main purpose.

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

Completeness2/5

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

Despite no output schema, the description is too sparse for a tool with 4 optional parameters and disambiguation logic. Lacks explanation of how noteId vs title resolve, or what happens when no identifier is provided.

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 description coverage is 100%, so baseline is 3. Description does not add any additional meaning to the parameters beyond what is in 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?

Description clearly states the purpose: 'Read a full Apple Note, including plaintext and HTML body.' The verb 'Read' and resource 'Apple Note' are specific and distinct from sibling tools like notes_search or notes_list_accounts.

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

Usage Guidelines2/5

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

No guidance on when to use this tool vs alternatives (e.g., notes_search for searches, notes_status for metadata). Does not explain disambiguation logic among title, noteId, folderName, accountName, nor when not to use it.

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

notes_list_accountsA

Read-only

List Apple Notes accounts available to the current macOS user.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds no behavioral details beyond stating the action, which is adequate but not enhancing.

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 clear sentence with no unnecessary words. It is front-loaded and 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?

For a zero-parameter tool with annotations present, the description sufficiently explains the purpose. It could be slightly more specific about what 'accounts' entails, but it is largely complete.

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?

There are no parameters, so schema coverage is effectively 100%. The description doesn't need to add parameter semantics, and the baseline score of 4 applies.

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 the specific resource 'Apple Notes accounts available to the current macOS user.' It distinguishes this tool from siblings like notes_list_folders or notes_search, which have different actions.

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 does not explicitly state when to use this tool versus alternatives. While the sibling tool names provide context, the description itself lacks guidance on usage context, such as prerequisites or when not to use it.

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

notes_list_foldersA

Read-only

List Apple Notes folders, optionally scoped to one account.

ParametersJSON Schema

Name	Required	Description	Default
`accountName`	No	Optional exact account name to filter folders.

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already indicate readOnlyHint=true and destructiveHint=false; the description confirms read-only listing behavior and adds scoping detail, consistent with no contradictions.

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 redundant words, efficiently conveys core functionality.

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 list tool with no output schema, the description covers key behavior (list folders, optional account filter); return format is not specified but acceptable for this tool's simplicity.

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% with clear parameter description; the description adds minimal extra meaning beyond 'optional scoping,' so baseline 3 is appropriate.

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 (list) and resource (Apple Notes folders) with optional scoping, distinguishing it from sibling tools like notes_search or notes_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 mentions optional scoping to one account, implying when to use the parameter, but lacks explicit guidance on when to use this tool versus alternatives like notes_search or notes_status.

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

notes_moveA

Destructive

Move a note to another folder, including folders in another account. Defaults to dryRun=true so clients can verify the resolved note and destination before moving.

ParametersJSON Schema

Name	Required	Description
`title`	No	Exact note title. Use with accountName/folderName when noteId is unknown.
`dryRun`	No	When true, resolve note and destination without moving.
`noteId`	No	Stable Apple Notes note ID. Prefer this over title.
`folderName`	No	Folder name used to disambiguate title lookup.
`accountName`	No	Account name used to disambiguate title lookup.
`destinationFolderId`	No	Destination folder ID.
`destinationAccountId`	No	Destination account ID.
`destinationFolderName`	No	Destination folder name.
`destinationAccountName`	No	Destination account name.

TDQS

A4.2/5.0

Behavior5/5

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

The description adds key behavioral context beyond annotations: it defaults to dryRun=true, allowing verification before moving, and supports cross-account moves. Annotations already indicate destructive intent, and the description aligns without contradiction.

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 concise sentences with no fluff. The first sentence states the core purpose, and the second provides critical default behavior upfront.

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 destructive tool with many parameters and no output schema, the description covers the main purpose, cross-account capability, and dryRun default. Missing details like error cases or response structure, but still sufficient for basic understanding.

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 description coverage is 100%, so the schema already documents all parameters. The description adds value by noting the dryRun default and advising use of accountName/folderName when noteId is unknown, but does not elaborate further on parameter constraints or relationships.

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 'move' and resource 'note', specifying the capability to move to another folder or even across accounts. This distinguishes it from sibling tools like notes_create, notes_update, and notes_delete.

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 using dryRun first but does not explicitly state when to use this tool versus alternatives (e.g., notes_update). No when-not-to-use guidance or prerequisites are provided.

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

notes_searchA

Read-only

Search Apple Notes by title and plaintext body. Returns stable IDs for follow-up read, update, move, and delete tools.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Maximum notes to return.
`query`	No	Case-insensitive text to search in note title and plaintext.
`folderName`	No	Optional exact folder name filter.
`accountName`	No	Optional exact account name filter.
`includeBodyHtml`	No	Include Notes HTML body in each result.
`includePlaintext`	No	Include plaintext body in each result.
`includeRecentlyDeleted`	No	Include notes in Recently Deleted folders.

TDQS

A4.2/5.0

Behavior4/5

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

Adds useful behavioral context beyond annotations: mentions stable IDs for subsequent operations. Annotations already confirm readOnlyHint=true, so no contradiction; description enhances understanding.

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, front-loaded sentence with no wasted words. Every piece of information is necessary and contributes to understanding the tool's purpose and usage.

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?

With no output schema, the description explains the key return value (stable IDs) and the tool's role in a workflow. It could be slightly more complete by mentioning that matching notes are returned, but the parameter options (includeBodyHtml, includePlaintext) imply that content can be included. Overall adequate.

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% with parameter descriptions. The tool description does not add any parameter-level details beyond what the schema provides, so baseline score of 3 is appropriate.

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?

Clearly states the verb (Search), resource (Apple Notes), and scope (by title and plaintext body). Mentions return of stable IDs for follow-up tools, distinguishing it from siblings like notes_get or notes_list_accounts.

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?

Explicitly states that returned IDs are for follow-up read, update, move, and delete tools, guiding when to use this tool. Does not explicitly name alternatives, but context is clear from sibling tool names.

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

notes_statusA

Read-only

Check whether Apple Notes automation is available and return account/note counts.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds value by specifying the tool returns availability and counts, which is beyond the annotations. No mention of authentication or rate limits, but the tool is simple and read-only.

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 wasted words. Front-loaded with the core action and outcome. Perfectly concise for a tool with no parameters.

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 status check tool with no input parameters and no output schema, the description provides enough context: it returns availability and counts. However, it does not specify the return format (e.g., JSON structure), which could be more precise. Overall sufficient for the tool's simplicity.

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 in the input schema, and schema description coverage is 100% trivially. The description does not need to add parameter info. Baseline for 0 parameters is 4, and no additional clarification is required.

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 checks Apple Notes automation availability and returns account/note counts. It uses a specific verb ('Check') and resource ('Apple Notes automation'), and the purpose is distinct from sibling tools like notes_list_accounts or notes_get.

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. The description implies it's a preliminary check before other operations, but does not state this directly or mention exclusions. The context of siblings provides some implicit usage context.

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

notes_updateA

Update a note title and/or HTML body. Prefer noteId lookup for correctness.

ParametersJSON Schema

Name	Required	Description
`noteId`	No	Stable Apple Notes note ID. Prefer this over title.
`bodyHtml`	No	Replacement note body as HTML.
`newTitle`	No	New note title.
`folderName`	No	Folder name used to disambiguate title lookup.
`accountName`	No	Account name used to disambiguate title lookup.
`currentTitle`	No	Exact current title, only used when noteId is unknown.

TDQS

A3.9/5.0

Behavior3/5

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

Annotations declare readOnlyHint=false and destructiveHint=false, so the description's 'update' is consistent. No additional behavioral context is provided (e.g., required permissions, idempotency, side effects), and the description only adds the noteId preference.

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 fluff. The key information (action, fields, lookup preference) is front-loaded and efficient.

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?

No output schema is provided, and the description does not mention return values or error handling. For a mutation tool with six parameters, this omission reduces completeness.

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 parameters are well-documented in the schema. The description only mentions title and HTML body, not the disambiguation parameters. This adds minimal value 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 (update), resource (note), and specific fields (title and/or HTML body). It also provides a usage hint ('prefer noteId'), distinguishing it from sibling tools like notes_create, notes_delete, etc.

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 includes guidance to prefer noteId lookup for correctness, implying when to use ID vs title-based lookup. However, it does not explicitly state when not to use this tool or mention alternative tools for related operations.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

10 tool updatesv0.1.0Jul 29, 2026
- First observednotes_create
- First observednotes_create_folder
- First observednotes_delete
- First observednotes_get
- First observednotes_list_accounts
- First observednotes_list_folders
- First observednotes_move
- First observednotes_search
- First observednotes_status
- First observednotes_update

Install Server

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

TDQS

A4/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: status, listing accounts, listing folders, searching, reading, creating, updating, moving, deleting notes, and creating folders. No two tools overlap in functionality.

Naming Consistency5/5

All tools follow the consistent 'notes_<action>' pattern using snake_case. Actions are clear verbs or verb-noun combinations (e.g., list_accounts, create_folder), forming a predictable naming convention.

Tool Count5/5

With 10 tools, the server is well-scoped for managing Apple Notes. It covers all essential operations without being overly numerous or too sparse.

Completeness4/5

The set covers the full lifecycle of notes (CRUD plus move) and major organizational features (accounts, folders, search). Minor gaps exist, such as missing folder deletion or rename, but core workflows are well supported.

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

notesbridgeOAuth
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
aNotepadOAuth
com.anotepad
AI access to your aNotepad online notes: read, search, write, and organize via 22 tools.
Note Taking Cloud Storage Search
2
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
KnowtisOAuth
app.knowtis
Create, search and manage Knowtis collaborative notes from AI assistants.
Note Taking Knowledge & Memory
21

Related MCP Servers

Apple Notes MCP Server
Note Taking Autonomous Agents
Siddhant-K-code
A
license
D
quality
B
maintenance
Enables interaction with Apple Notes via natural language, supporting note creation, search, and retrieval with iCloud integration for seamless note management.
Updated 24 days ago (2026-08-13 07:33 UTC)
3
17
24
MIT
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 6 months ago (2026-03-20 17:57 UTC)
8
433
27
MIT
mcp-inotes
Note Taking App Automation
pongsapakl
A
license
A
quality
D
maintenance
Enables LLMs to create, read, and append notes in Apple Notes through AppleScript, with append-only operations restricted to a single folder for safety.
Updated 8 months ago (2026-01-15 01:36 UTC)
4
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/taylorarndt/apple-notes-mcp'

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