Bottari defines 7 tools with complete input schemas and clear descriptions. Naming follows verb_noun convention (bottari_status, bottari_sync, bottari_resolve_conflicts). Descriptions are concise (20-180 chars) and explain state-changing behavior. However, parameter descriptions are sparse or missing entirely, most parameters lack guidance on format, constraints, or dependencies. Output schemas are not documented. Error handling is minimal; no recovery guidance or actionable error messages visible. Tool composition is sound (each does one thing), but parameter documentation falls short of production baseline (100% of A+ tools have param descriptions; this server has ~40% coverage).

• Add descriptions to all parameters. For 'id' in bottari_get_conflict_diff: 'The conflict ID returned by bottari_sync in the conflicts array.' For 'limit' in bottari_list_generations: 'Maximum number of generations to return (1 - 100, default 20).' For 'generation' in bottari_restore: 'The generation number to restore from (must be ≤ current generation).'
• Document output schemas in tool definitions. E.g., bottari_sync returns {status: 'done'|'partial', generation: number, uploaded: number, downloaded: number, conflicts: [{id, choice}], sessionCredentialFindings: array}. Include this in the tool definition so LLMs know what fields to expect.
• Enhance error messages with recovery guidance. Instead of 'No bundle in the cloud', return 'No bundle in the cloud. Run `bottari init` in a terminal first, then retry.' This tells the LLM what action to suggest to the user.
• Add min/max constraints to numeric parameters. bottari_list_generations 'limit' should specify range (1 - 100). bottari_restore 'generation' should validate it is a positive integer ≤ current generation.
• Clarify parameter dependencies in descriptions. bottari_resolve_conflicts 'resolutions' array contains objects with 'id' and 'choice', document that 'choice' must be one of the enum values and that 'id' must match a conflict from the previous bottari_sync call.