Search Notes
search_notesSearches Apple Notes by title or content.
Paginated: limit is capped at 100 per call, so page with offset instead of asking for a bigger limit. The response carries total (how many notes match the query in all) and has_more, so a capped page is never mistaken for the complete answer — page until has_more is false, which is exact even when total_is_estimated says the count is only a lower bound. To walk every match, pass order="id" — see the order parameter.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Matches per page (default 20, capped at 100). To get more, page with offset. | 20 |
| order | No | order: "modified" (default) sorts newest-modified first — what you want to SHOW someone, but NOT safe for paging: modification date changes, so a note edited between two calls jumps to the front and another note is pushed past your cursor and never returned. "id" sorts by the note's immutable store id — stable, never renumbered, new notes append at the end — so use order="id" to walk an entire library page by page: edits and insertions mid-crawl are safe with it. One case it cannot cover, because pages are addressed by offset: if a note is DELETED mid-crawl, every note after the hole shifts one slot back and the note that was on the page boundary is skipped, silently. If completeness matters, re-run the crawl and reconcile against total, or crawl while nothing is deleting notes. | modified |
| query | Yes | ||
| offset | No | How many matches to skip (default 0). An offset past the end returns an empty page with has_more=false, not an error. | 0 |
Output Schema
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | Matches in THIS page | |
| order | No | The ordering actually applied (modified | id) | |
| query | No | ||
| total | No | Matches in total, ignoring limit/offset. A LOWER BOUND, not the exact figure, when total_is_estimated is true | |
| offset | No | Where this page started | |
| results | No | ||
| has_more | No | True when matches remain past this page — call again with offset = offset + count | |
| next_actions | No | ||
| total_is_estimated | No | True when the exact count could not be taken (the unbounded COUNT failed, or the JXA fallback answered) — total is then only a lower bound. has_more stays exact either way: page until it is false, never until count reaches total |