Server has 8 tools with consistent naming (verb_noun pattern: get_*) and Italian descriptions. All tools are READ_ONLY analytics/reporting. Schemas are present but minimal, most parameters lack type constraints (no enums, no min/max bounds). Descriptions are adequate (50-150 chars) but lack actionable guidance on when to use each tool vs. alternatives. No error handling guidance, no output schema documentation, no parameter validation rules stated. Tool composition is sound (single responsibility), but parameter descriptions are generic ('Data inizio periodo' without format examples). Missing: pagination guidance for list tools, output field documentation, recovery hints for common failures.

• Add enum constraints to all categorical parameters. E.g., get_cashbook_entries 'type' should declare enum: ['in', 'out', 'all']. Use JSON Schema 'enum' field, not just description text.
• Document output schemas for all tools. Create a schema definition showing response field names, types, and which fields are IDs/references needed by downstream tools. E.g., get_clients must return client_id so get_client_invoices can accept it.
• Add min/max bounds to numeric parameters. E.g., 'limit' should state 'integer, 1 - 200, default 20' not just 'default: 20'. Add date range constraints: 'from_date must be within last 5 years'.
• Enhance parameter descriptions with validation rules and examples. E.g., 'year (integer, 2020 - 2026, default: current year)' instead of 'Anno di riferimento, default: anno corrente'.
• Add recovery hints to tool descriptions. E.g., get_clients: 'If no results, try search with partial name or call get_payment_accounts to verify API access.' This guides LLM on fallback strategies.

Inferred effective spec: 2026-07-28+.

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