Server has 7 tools with complete input schemas and descriptions. Naming follows verb_noun convention (notify_send, notify_withdraw, etc.). Descriptions are present but brief (avg ~60 chars, below the 194-char baseline). Parameters are typed and described, but lack constraints (enums, ranges, formats). Output schemas are not documented, LLMs cannot predict response structure. Error handling is minimal; no recovery guidance. Tools are well-scoped (single responsibility), but composition could be stronger, no batch operations despite multiple write tools.

• Document output schemas for all tools. Example: notify_send should return {success: boolean, notification_id?: string, error?: string}. notify_list_delivered should return {notifications: [{id, title, body, timestamp}], actions: [{notification_id, action_id, timestamp}]}.
• Add enum constraints for 'sound' parameter (e.g., 'Ping', 'Pop', 'Glass', 'Submarine', or null for default). Validate against macOS UNNotificationSound valid names.
• Expand descriptions to 100-200 chars. Example: notify_check_authorization → 'Check if the app has notification permissions. Call this before notify_send to verify authorization status. Returns authorization level (denied, provisional, authorized) and individual settings (alert, sound, badge).'
• Add error recovery guidance. Example: notify_send description should include 'If authorization is denied, the user must enable notifications in System Preferences > Notifications.'
• Implement dry-run or confirmation for notify_withdraw and notify_configure_quiet_hours. Add optional 'confirm' parameter or separate 'preview_quiet_hours' tool to let agents review changes before applying.

Inferred effective spec: 2026-07-28+.

• Current-spec patterns present: Multi Round-Trip Requests, structured tool output