How I Built a Local Apple Notes MCP Server to Give Claude Desktop Real Note Automation

A developer built a local MCP server for Apple Notes that gives Claude Desktop 13 tools for note automation, including search, move, append, and delete capabilities beyond the official integration. The server uses AppleScript to connect Apple Notes to AI assistants via the Model Context Protocol, enabling natural language commands like "summarize my notes from last week" or "add this to my shopping list." The project is open-source on GitHub.

I wanted to ask Claude about my notes the way I ask it about everything else: naturally, without copying and pasting between apps or manually organising information one note at a time. I wanted to say things like “summarize my notes from last week,” “find the idea I wrote about product onboarding,” or “add this to my shopping list,” and have the assistant actually do the work. That sounds simple. In practice, it exposed a gap that many people do not think about until they hit it: AI assistants can be very good at reasoning, but they are only as useful as the tools they can reach. For Apple Notes, that gap was real. The official Apple Notes integration in Claude Desktop was useful, but it was also narrow. It let me read and create notes. That was enough to prove the concept, but not enough to build a real workflow around it. I could not search notes, move them between folders, append to an existing note, or delete them in a way that felt practical. It was a starting point, not a proper bridge. So I built my own. Not a cloud service. Not a wrapper around a third-party API. Just a local MCP server that runs on my machine, talks to Apple Notes through AppleScript, and exposes the tools Claude needs to work with my notes in a more serious way. The code is available on GitHub so other people can try it and extend it: https://github.com/Manu-jemini/apple-notes-mcp https://github.com/Manu-jemini/apple-notes-mcp That is what this project became: a small but meaningful piece of infrastructure that turns Apple Notes from a passive repository into something an AI assistant can actually operate. The Model Context Protocol is one of those ideas that sounds abstract until you see it in action. At a high level, MCP gives an AI assistant a structured way to call tools. Instead of forcing an LLM to “pretend” it can interact with an app, the protocol lets the application expose real capabilities: search, create, update, delete, move, and so on. In other words, MCP is the missing layer between an AI model and the tools you use every day. That is why it matters. Once an app exposes its functionality through MCP, the AI does not need to guess how to interact with it. It just calls the tool that exists. For a personal productivity stack, that is huge. It means your notes, your tasks, your documents, your calendar, and your files can all become part of a larger reasoning loop. The goal is not just “AI can read your notes.” The real goal is “AI can act on your notes.” I spend a lot of time writing ideas down. Some of them become projects. Some become blog posts. Some are just half-formed thoughts that I want to keep around until I have time to make sense of them. The issue was that my notes lived in a system that was great for capture but not great for retrieval or automation. I wanted something closer to how I actually think: That is where Apple Notes and Claude started to feel incomplete together. The default integration gave me some basic read/write capabilities, but not enough to make the experience feel natural. I wanted a server that could do more than just “create a note.” I wanted a server that could support real note workflows. So I built one with 13 tools. The server is intentionally simple. It runs locally, uses AppleScript to talk to Apple Notes, and exposes a set of tools that Claude can call when needed. It includes tools for: That is the difference between a toy integration and a usable one. The first one proves the idea. The second one supports real work. The structure is intentionally straightforward. There is an entry point that starts the MCP server and connects it to stdio, which is the transport MCP uses. From there, the server registers a set of tool handlers. Each tool is implemented in its own file, which keeps the code easy to reason about and easy to extend. The core pattern is very consistent: That simplicity matters. It keeps the server predictable and makes it much easier to add new behaviors later. Here is the core entry point: js import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";import { createServer } from "./server"; js const server = createServer ; js async function main { const transport = new StdioServerTransport ; await server.connect transport ;} main .catch console.error ; The server itself is just a registry of tools. That is the beauty of it. Once the transport is live, Claude can call the tools as if they were part of the assistant’s native skill set. One of the reasons I liked this approach is that it avoids the usual AI-product trap: sending personal data to a third party just to make it usable. The MCP server itself runs on my machine. It talks to Apple Notes through AppleScript, and it does not use a separate cloud note backend or a third-party note-sync service. That means the note access and the tool execution are local to the machine where the server runs. However, there is an important distinction here: the server can keep your notes local, but the assistant that uses the tool may still send the tool output to Claude Desktop’s model service, depending on how your Claude setup is configured. So this architecture reduces one layer of exposure by keeping the note integration local, but it does not change the broader inference path used by Claude Desktop. That is not just a privacy preference. It is also a practical design decision. When you build tools that operate on personal data, the simplest and safest model is usually the one that keeps the data where it already lives. For this kind of project, local-first is not a compromise. It is the right architecture. Apple Notes does not expose a modern developer API that is friendly to this kind of integration. On macOS, AppleScript is still the most practical way to interact with the app. That comes with tradeoffs. AppleScript is old, sometimes awkward, and not especially elegant. But it is direct. And for a local desktop environment, direct is often more valuable than polished. The server uses AppleScript to do things like: It is a simple bridge, but it is effective. One of the most important pieces of the implementation is also one of the simplest: escaping user input before it is placed into AppleScript. If you insert raw text into an AppleScript string, you can create injection issues. That is not a theoretical concern. It is a real risk when user content is mixed into a script. The implementation uses a small helper to escape quotes safely before passing content into AppleScript strings. It is a tiny detail, but it matters a great deal when the system is supposed to be trustworthy. That is the kind of hardening that makes a personal automation tool feel serious rather than experimental. The interesting part is not just that the tool exists. It is that it changes how the assistant can behave. Instead of saying “here is a list of your notes,” Claude can now do things that feel much closer to real assistance. Examples: That is the difference between passive access and real workflow integration. The full project is hosted on GitHub so you can clone it, inspect it, and start from the same working example: https://github.com/Manu-jemini/apple-notes-mcp https://github.com/Manu-jemini/apple-notes-mcp Once the server is built, connecting it to Claude Desktop is straightforward. You add the server to your Claude Desktop configuration: { "mcpServers": { "apple-notes": { "command": "node", "args": "/absolute/path/to/apple-notes-mcp/dist/index.js" } }} Then build the project: npm installnpm run build Restart Claude Desktop, and the server appears as a connected MCP tool provider. From that point on, the assistant can use the tools it exposes. One small caveat: if Claude Desktop cannot find Node, use the absolute path to your Node binary instead of just node. There is a difference between building an AI feature and building a real AI workflow. A feature is something the model can technically do. A workflow is something the model can do repeatedly, reliably, and in a way that feels like part of a larger system. That is what this server tries to enable. It is not just another connector that can read notes. It is a way to make Apple Notes part of the same kind of loop that already exists for code, files, browser tools, and other productivity systems. That is why I think this kind of project matters. It shows that the real future of AI assistants is not just better chat. It is better integration with the tools we already use every day. The process reinforced a few ideas that I think are worth keeping in mind. First, AI tools become much more useful when they are connected to real systems rather than just exposed as text. The moment an assistant can take action, the experience changes completely. Second, the hardest part is rarely the core idea. It is usually the plumbing: handling errors, keeping the transport clean, making sure inputs are safe, and making the tool interface predictable. Third, a simple architecture tends to win. A server with a clear structure, a few well-defined tools, and direct local execution is easier to maintain and easier to extend than something more clever but more fragile. That is what made this project satisfying. It was not about trying to over-engineer the problem. It was about building a useful bridge in a way that felt durable. The most exciting part of all of this is not the Apple Notes integration itself. It is the pattern. Once you can connect an AI assistant to a local system through MCP, the possibilities expand quickly. Notes become actionable. Documents become searchable. Personal knowledge becomes usable by the assistant in a more meaningful way. This project is small, but the idea behind it is much larger: if your tools are accessible, your AI assistant becomes far more useful. And once that happens, the assistant stops feeling like a chatbot and starts feeling like a collaborator. How I Built a Local Apple Notes MCP Server to Give Claude Desktop Real Note Automation https://blog.devgenius.io/how-i-built-a-local-apple-notes-mcp-server-to-give-claude-desktop-real-note-automation-2e81753f9ba2 was originally published in Dev Genius https://blog.devgenius.io on Medium, where people are continuing the conversation by highlighting and responding to this story.