Two tools with basic descriptions and minimal schemas. add_note has a single string parameter with description; read_notes has no parameters. Both descriptions are present but brief (34-56 chars, below the 50-200 char LLM-optimized baseline). No output schemas documented. No error handling guidance, no parameter constraints, no idempotency hints. Tool names follow verb_noun convention (add_, read_) but lack context about side effects and recovery paths. No validation, no pagination, no structured output specification.

• Expand add_note description to 80-150 chars: 'Append a new note to the sticky note file. This operation is idempotent, calling with the same message twice will create two separate entries. Returns confirmation on success; fails if file is not writable.'
• Expand read_notes description to 80-150 chars: 'Retrieve all notes from the sticky note file as a newline-separated string. Returns 'No notes yet.' if the file is empty. Use this to review all notes before adding new ones.'
• Document output schemas explicitly: add_note returns {type: 'string', description: 'Confirmation message'}; read_notes returns {type: 'string', description: 'All notes separated by newlines, or default message if empty'}.
• Add error handling: catch file I/O exceptions and return structured errors like 'File not writable: check permissions on notes.txt' (user-fixable) vs 'Disk full' (retryable).
• Add tool annotations via FastMCP: mark add_note with destructiveHint=true to signal state modification; mark read_notes with readOnlyHint=true to signal safe retry.