Loading ToolBench
MCP server for Apple Notes with semantic search and CRUD operations
Apple Notes MCP has strong overall structure with 24 well-defined tools covering a comprehensive domain (search, CRUD, indexing, graph operations). Most tools have descriptions and input schemas. However, there are notable gaps: (1) Many parameter descriptions are minimal or absent, e.g., 'related-notes' has types/enums but sparse field documentation; (2) Output schemas are not explicitly documented in the source, callers must infer structure from implementation; (3) Error handling guidance is present in error classes (NoteNotFoundError, DuplicateNoteError) but not surfaced in tool descriptions to guide LLM recovery; (4) Some tool naming could be clearer, e.g., 'index-notes' vs 'start-index-job' vs 'reindex-note' creates subtle distinctions that LLMs may conflate; (5) Destructive operations (delete-note, batch-delete, purge-index) have confirmation flags but descriptions don't explicitly warn about irreversibility. Overall: definitions are above-average for a community server but fall short of production-grade polish expected for sensitive operations on user data.
Delete multiple notes by title or folder
Move multiple notes to a target folder
Cancel a running background indexing job
Create a new note
Delete a note (requires confirmation)
Edit cells in a table within a note
Export knowledge graph as JSON or GraphML
Output schemas not documented. Tool descriptions do not specify what fields are returned or their types, forcing LLMs to infer response structure. E.g., search-notes returns results but LLMs cannot determine if they get 'title', 'id', 'preview', 'tags', 'similarity_score', etc.
Destructive operation descriptions lack irreversibility warnings. delete-note, batch-delete, and purge-index have confirmation flags but descriptions don't explicitly state the operation is destructive and permanent. LLMs need explicit warnings to treat these with caution.
Error recovery guidance missing from tool descriptions. While error classes exist (NoteNotFoundError, DuplicateNoteError), the tool descriptions don't tell LLMs what to do when errors occur. E.g., 'If note not found, try search-notes first' is absent.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 62 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 46 | - | v1 |
Get background indexing job status and progress
Get note content by title
Extract and parse tables from a note
Index all notes for semantic search. Use mode='incremental' (default) to only process changed notes.
List all folders containing notes
List recent background indexing jobs
List all notes with optional sorting and filtering
List all tags from the knowledge graph
Move note to a different folder
Delete all indexed data (requires confirmation)
Reindex a single note
Find notes related to a given note by tags, links, or similarity
Search notes by tag
Search note chunks using the Parent Document Retriever pattern
Search notes using hybrid vector + fulltext search
Start background indexing job and return job id for polling
Update note content and optionally reindex
Naming confusion among indexing tools. Three tools (index-notes, start-index-job, reindex-note) handle indexing but with unclear distinctions. 'index-notes' with background=true and 'start-index-job' do similar things, LLMs may conflate them. Consider renaming to 'trigger-background-index' or consolidating.
Parameter descriptions sparse or generic. Many tools have enum constraints but descriptions are minimal: 'Job ID', 'Note title', 'Tag name'. These don't help LLMs understand when to call the tool or what distinguishes it from similar tools.
Batch operations lack clear guidance on atomic vs partial failure semantics. batch-delete and batch-move don't specify: if deleting 5 notes and 2 fail, are the other 3 deleted? Are partial failures returned per-item or as a blanket error?
Title-based note lookup ambiguity. get-note and update-note accept 'title' as the only identifier, but DuplicateNoteError in errors/index.ts shows notes can have duplicate titles. Tools should support ID-based lookup or clearly document that title must be unique.