The server defines 12 tools with consistent naming (verb_noun pattern) and basic schemas. All tools have descriptions and input parameters with types. However, descriptions are minimal (10-50 chars, well below the 194-char baseline), lack context on WHEN to use each tool, and omit error recovery guidance. Output schemas are not documented. Parameter descriptions are sparse, many lack format/constraint details. No tool annotations (readOnlyHint/destructiveHint) despite clear risk levels. Error handling is absent from visible code. Composition is sound (single responsibility per tool), but descriptions need expansion to meet LLM-optimization standards.

• Expand all tool descriptions to 100-200 chars. Include WHAT the tool does, WHEN to use it (vs similar tools), and what it returns. Example: 'Create a new note in the default project. Use this to capture ideas, tasks, or reference material. Returns note_id for use in update_note or delete_note.'
• Add tool annotations: mark read-only tools with readOnlyHint=true, destructive tools (delete_note) with destructiveHint=true, and idempotent tools with idempotentHint=true. This enables agents to reason about retry safety.
• Document output schemas for all tools. Specify returned fields, types, and which IDs/references are needed for downstream calls. Example: create_note returns {note_id: string, title: string, created_at: ISO8601}.
• Add parameter constraints: limit (1-100, default 20), offset (≥0), tags (max 10 items, max 50 chars each), query (max 500 chars). Include these in parameter descriptions, not just JSON Schema.
• Add error handling guidance to descriptions. Example for delete_note: 'Permanently deletes a note. Returns 404 if note_id not found; 403 if user lacks permission. No undo available, consider archiving instead.'