Demo server has 5 tools with basic schemas and descriptions. All tools have names starting with action verbs (search_, save_, list_, delete_, admin_). Descriptions are present but minimal (10-30 chars), below the 50-200 char baseline for LLM-optimized docs. Input schemas exist but are sparse: most parameters lack detailed constraints, enums, or format guidance. No output schemas documented. Error handling is absent, no recovery guidance, no categorization of retryable vs fatal errors. The destructive tools (delete_note, admin_reset) lack confirmation patterns or dry-run support. Tool composition is reasonable (each does one thing), but parameter descriptions are generic.

• Expand all tool descriptions to 50-150 chars. Example: 'search_notes' → 'Search all notes by keyword. Returns matching note IDs, titles, and snippets. Use this to find notes before editing or deleting.'
• Document output schemas for all tools. Specify: search_notes returns {results: [{id, title, snippet}], total_count}, list_notes returns {notes: [{id, title, created_at}]}, save_note returns {id, title, created_at}.
• Add parameter constraints: 'query' (1-100 chars, alphanumeric + spaces), 'id' (positive integer), 'title' (1-200 chars), 'content' (1-10000 chars). Use enums or regex patterns in schema.
• Implement confirmation pattern for destructive tools: add a 'confirm' boolean parameter (default false) to delete_note and admin_reset. Require confirm=true to execute; return a warning on first call.
• Add error handling: return structured errors with actionable guidance. E.g., 'Note not found (id=123). Call list_notes() to see available notes.' Categorize errors as retryable (network timeout) vs user-fixable (invalid id).