Skip to main content
Glama

Search Notes

search_notes
Read-only

Searches 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

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMatches per page (default 20, capped at 100). To get more, page with offset.20
orderNoorder: "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
queryYes
offsetNoHow 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

TableJSON Schema
NameRequiredDescriptionDefault
countNoMatches in THIS page
orderNoThe ordering actually applied (modified | id)
queryNo
totalNoMatches in total, ignoring limit/offset. A LOWER BOUND, not the exact figure, when total_is_estimated is true
offsetNoWhere this page started
resultsNo
has_moreNoTrue when matches remain past this page — call again with offset = offset + count
next_actionsNo
total_is_estimatedNoTrue 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

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true, but the description adds rich behavioral details: pagination mechanics (limit cap, offset), response fields (total, has_more, total_is_estimated), order semantics (instability of modified, deletion shifts with offset), and edge cases (offset past end returns empty page). This exceeds annotation coverage.

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 short paragraphs, front-loaded with the purpose, then efficiently covers pagination, order modes, and edge cases. Every sentence adds value with no repetition or fluff.

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

Completeness5/5

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

Given the complexity of pagination and order modes, the description covers all key behaviors: limit cap, offset, response indicators, total estimation, order stability, and deletion edge cases. An output schema exists, so description rightly focuses on usage nuances. Complete for agent invocation.

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 high (75%) with detailed descriptions for limit and order. The description adds context for query ('by title or content') and reiterates pagination guidance, but does not significantly enhance understanding beyond the schema. 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 'Searches Apple Notes by title or content', using a specific verb-resource combination. This distinguishes it from siblings like create_note, read_note, and list_notes, making the tool's function unambiguous.

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 provides detailed guidance on pagination: limit cap, offset usage, and when to use order='id' vs 'modified' for stable paging. However, it does not explicitly compare to sibling tools like list_notes or search_contacts, so it lacks alternative recommendations.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.5/5.0
Disambiguation3/5

Many tools are clearly distinct per app (e.g., chrome_*, safari_*, m365_*), but there is notable overlap between generic file tools like `file_list` and `finder_list`, both listing files; `search_contacts` and `list_contacts` serve similar purposes; `report_friction` and `report_problem` both send feedback to the team. The large number of tools with similar purposes in different domains creates moderate ambiguity for an agent.

Naming Consistency4/5

The naming convention is very consistent overall: most tools follow a `{app}_action` or `verb_noun` pattern (e.g., `chrome_click`, `create_calendar_event`, `list_reminders`). There are minor deviations like `lmcp_install_upgrade` (two verbs) and `complete_omnifocus_task` vs. `complete_reminder` (inconsistent verb placement). Still, the pattern is predictable and readable across the full set.

Tool Count2/5

With 225 tools, the surface is extremely large and heavy. While it covers many distinct domains (browsers, mail, calendar, files, notes, reminders, video editing, web automation, etc.), the sheer number makes it hard to navigate and likely includes many rarely-used tools. This is far beyond the well-scoped range of 3-15 tools and feels excessive even for a 'local everything' MCP server.

Completeness3/5

For many app integrations, the tool set provides solid CRUD coverage (e.g., Calendar has create, read, update, delete; Apple Notes has create, read, update, list, search; OmniFocus has create, list, search, complete). However, some areas are incomplete: for example, there is no tool to create a new Mail folder or delete notes. The 'web' tools lack a clear update/delete for saved sessions. The suite is broad but has notable gaps within individual domains.