All 5 tools lack input parameter schemas entirely, critical blocker. Descriptions are present but generic (50-90 chars), missing WHEN/WHY guidance. No output schemas documented. Tools return JSON strings rather than structured objects. No error recovery guidance. No parameter descriptions. Naming is acceptable (verb_noun pattern) but insufficient to overcome schema absence.

• Add explicit JSON Schema input definitions to all tools. Even read-only tools should declare {} as an empty object schema with type: 'object', properties: {}, required: [].
• Document output schemas for each tool. Define the structure of system_info, utilisation, packages, volumes, and disks objects with field types and descriptions.
• Expand descriptions to 150-250 characters. Include: what data is returned, when to call (e.g., 'Call before troubleshooting performance issues'), and any prerequisites (e.g., 'Requires DSM admin credentials').
• Implement structured error responses with classification. Return {error: 'connection_failed', message: '...', retryable: true, next_step: 'Check SYNOLOGY_HOST and network connectivity'} instead of generic internal_error.
• Add pagination to list_packages, get_volumes, get_disks. Accept limit (default 20, max 100) and offset parameters. Return total_count and next_offset in response.

Inferred effective spec: <=2025-11-25.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry