Skip to main content
Glama
ailenshen

Apple Notes MCP Server

update_note

Modify existing Apple Notes by replacing content with new Markdown while keeping the original folder location.

Instructions

Update an existing note in Apple Notes. Deletes the old note and creates a new one with the given Markdown content, preserving the original folder.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
titleYesTitle of the existing note to update
markdownYesNew Markdown content for the note. First line (with or without #) becomes the title.
folderNoFolder name to scope the search for the existing note

Implementation Reference

  • The implementation of update_note, which finds the original note folder, deletes the existing note, and creates a new one with the updated content.
    export async function updateNote(
      title: string,
      markdown: string,
      folder?: string
    ): Promise<string> {
      // 1. Find the note's current folder via SQLite
      const row = findNoteByTitle(title, folder);
      if (!row) throw new Error(`Note not found: ${title}`);
      const originalFolder = row.folder || "Notes";
    
      // 2. Delete the old note
      await deleteNote(title, folder);
    
      // 3. Create the new note in the original folder
      return createNote(markdown, originalFolder);
    }
Behavior4/5

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

With no annotations provided, the description carries full burden and adds valuable behavioral context: it discloses that the operation is destructive ('Deletes the old note and creates a new one'), specifies the content format ('Markdown'), and notes preservation of the original folder. It doesn't cover permissions, rate limits, or error handling, but provides key implementation details beyond basic update semantics.

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 front-loaded with the core purpose in the first sentence, followed by implementation details in the second. Both sentences earn their place by adding clarity and behavioral context without redundancy. It's efficiently structured with zero waste.

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?

For a mutation tool with no annotations and no output schema, the description is moderately complete: it covers the destructive behavior and content format, but lacks details on error cases (e.g., if note doesn't exist), return values, or side effects. Given the complexity and missing structured data, it should do more to compensate, but provides a functional overview.

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 (title, markdown, folder). The description adds minimal semantics: it clarifies that 'markdown' content determines the title from the first line, but doesn't explain parameter interactions or usage beyond what the schema provides. Baseline 3 is appropriate as the schema does the heavy lifting.

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 specific action ('Update an existing note'), resource ('in Apple Notes'), and method ('Deletes the old note and creates a new one with the given Markdown content, preserving the original folder'). It distinguishes from siblings like create_note (creates new), delete_note (removes), and get_note/list_notes/search_notes (read-only).

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 by specifying it updates 'an existing note' rather than creating a new one, which differentiates it from create_note. However, it lacks explicit guidance on when to use this tool versus alternatives like editing content directly or when not to use it (e.g., for minor edits). No prerequisites or exclusions are mentioned.

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

Install Server

Other Tools

Latest Blog Posts

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/ailenshen/apple-notes-mcp'

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