Strong foundation with 19 well-named tools following verb_noun convention (list_, get_, create_, update_, account_). All tools have descriptions (avg ~80 chars, within baseline 34-392). Input schemas present for all tools with type declarations and parameter descriptions. Tool annotations (readOnlyHint) correctly applied. Key gaps: output schemas not documented in source; error handling guidance minimal; some parameter descriptions lack format/constraint details (e.g., date_from/date_to accept YYYY-MM-DD but not explicitly validated in visible code); no enum constraints for movement_type or accounting_status despite fixed valid values.

• Document output schemas for all tools. For list_* tools, specify: returned fields, total_count or next_cursor for pagination, and IDs needed for chaining (e.g., list_invoices must return invoice_id for get_invoice).
• Add JSON Schema format declarations for date parameters (format: 'date' for YYYY-MM-DD) and numeric ranges (minimum/maximum for limit/offset). This makes constraints machine-parseable and prevents LLM hallucination.
• Convert movement_type parameter to enum in create_stock_movement and list_stock_movements. Define valid values explicitly: ['příjemka', 'výdejka'] or English equivalents ['receipt', 'issue'].
• Enhance error messages with recovery guidance. E.g., 'Invalid evidence name. Call list_evidences() to see available options.' This enables agents to self-correct without dead-ending.
• Implement confirmation pattern for write operations: create_stock_movement and account_invoice should return a diff/preview and require explicit user approval before executing. Use WriteBudget/execute_write pattern visible in imports.

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

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