Skip to main content
Glama

local-mcp

by com.local-mcp

List Notes

list_notes
Read-only

Lists notes from Apple Notes app. Optionally filter by folder.

Paginated: limit is capped at 500 per call, so page with offset (offset=500 returns notes 501-1000) instead of asking for a bigger limit. The response carries total (how many notes match in all) and has_more (whether anything is left past this page), so you never have to guess whether you got everything — page until has_more is false, which is exact even when total_is_estimated says the count is only a lower bound. To read a WHOLE library, pass order="id" — see the order parameter.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoNotes per page (default 50, capped at 500). To get more, page with offset.50
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
folderNo
offsetNoHow many notes to skip (default 0). offset=500 with limit=500 returns notes 501-1000. An offset past the end returns an empty page with has_more=false, not an error.0

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
countNoNotes in THIS page
notesNo
orderNoThe ordering actually applied (modified | id)
totalNoNotes matching in total, ignoring limit/offset. A LOWER BOUND, not the exact figure, when total_is_estimated is true
offsetNoWhere this page started
has_moreNoTrue when notes 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.9/5.0
Behavior5/5

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

Annotations already mark `readOnlyHint: true` and `destructiveHint: false`, so no further disclosure needed on safety. The description adds extensive behavioral context: pagination mechanics (500 limit, offset logic), response fields (`total`, `has_more`, `total_is_estimated`), and ordering stability pitfalls (modified vs. id order, deletion hole problem). This significantly enriches agent understanding beyond the annotations alone.

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. The pagination and ordering detail is structured logically (problem → solution → edge case). Every sentence adds distinct value — no waste. It's concise for the complexity it covers.

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 there are 4 parameters (0 required), annotations cover safety, and an output schema exists, the description is complete. It covers pagination semantics, ordering pitfalls, deletion edge case, and response fields without needing to explain return values (output schema handles that). No gaps remain for the agent's practical use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 75%, meaning most parameters have some description, but the description adds deep value on `order` (explains the difference between 'modified' and 'id' with concrete scenarios) and `offset` (documents behavior past end). The `folder` parameter has no description in either schema or description, which prevents a 5. For a 4-param tool, the description compensates well for the schema gap.

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 it 'Lists notes from Apple Notes app' and optionally filters by folder. This is a specific verb+resource+scope that distinguishes it from siblings like 'search_notes' (which implies full-text search) and 'read_note' (which retrieves a single note by ID).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly explains when to use pagination (page with `offset` instead of asking for a bigger limit), how to walk a whole library safely (use `order="id"`), and when pagination is fragile (deletions mid-crawl shift offsets). No explicit 'when-not-to-use', but the behavioral detail is so rich that it effectively guides selection over siblings like `search_notes` or `read_note`.

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

All local-mcp toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

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.

Resources