9 tools with minimal parameter schemas and inconsistent descriptions. Most tools have empty input schemas ({}), making them unsuitable for LLM reasoning about preconditions or parameter validation. Descriptions range from adequate (status, consumables) to vague (find_vacuum). No output schemas documented. No error handling guidance. Tool naming follows verb_noun convention (good), but lack of structured input/output severely limits agent composability. Baseline: 549 production tools average 4 params per tool with full type+description coverage; this server has 8 tools with zero params and 1 with minimal schema.

• Add explicit input schemas to all 8 tools with empty {} schemas. Even stateless tools should declare 'type: object, properties: {}, required: []' to signal intentional zero-parameter design.
• Document output schemas for status, consumables, list_rooms, clean_room. Example: 'Returns {state: string, battery_percent: int, fan_speed: int, charging_state: string, fault_code: int}' for status.
• Expand descriptions for action tools to 100-150 chars. Include: what happens, when to use it, and any side effects. E.g. 'Start a full-house cleaning job immediately. The vacuum will leave the dock and begin mapping. Cannot be called while already cleaning.'
• Add error handling guidance to destructive tools (start_cleaning, stop_cleaning, clean_room). Document: 'If the vacuum is already cleaning, returns error 'already_cleaning'. Retry after calling stop_cleaning().'
• For clean_room, add enum constraint or reference: 'room: string (numeric ID or alias from list_rooms). E.g. '0', 'living_room', 'bedroom'. Call list_rooms first to see available aliases.'