Strong foundation with 15 well-named tools following verb_noun convention (list_, read_, create_, update_, search_, restore_). All tools have descriptions (avg 156 chars, within 10-1024 baseline). Input schemas present with typed parameters. However, output schemas are not documented, LLMs cannot predict response structure for chaining. Parameter descriptions are present but inconsistent in depth; some lack format/constraint details. Error handling is minimal, no recovery guidance or actionable error messages visible. Tool composition is sound (single responsibility, clear chains via filename/id references). Security: no credentials exposed as parameters (good). Missing: pagination guidance for list_notes and search despite potentially large result sets.

• Document output schemas for all tools. E.g., list_notes returns [{filename, tags: string[], preview, kind, created_at, device_context}]. Include field types and nested structure so LLMs can plan chaining.
• Add pagination to list_notes, search, list_glyphs, list_places: accept limit (1-100, default 20) and offset/cursor; return total_count and next_cursor. State in descriptions: 'Results are paginated; use limit and offset to fetch large datasets.'
• Implement error recovery guidance. When update_note fails with revision mismatch, return: 'Note was modified since last read. Call read_note() to fetch the latest revision, then retry update_note().' Categorize errors as retryable, user-fixable, or fatal.
• Add format constraints to parameter descriptions. E.g., 'date (YYYY-MM-DD, e.g. 2026-03-20)', 'limit (1-500, default 500)', 'name (lowercase letters, digits, _, +, -, max 32 chars)'. Use enums for save_glyph format: ["png", "svg"].
• Add confirmation step for destructive operations. E.g., update_note and restore_note should accept a 'confirm' boolean parameter (default false). When false, return a preview of changes and ask user to confirm. When true, apply the change.