Significant quality gaps across all three tools. Tool definitions are loaded dynamically from YAML and JSON files (device_control_tools.ts), making it impossible to verify actual schema definitions in source code. The three visible tools (SwitchBotTVControlFunction, SwitchBotLightControlFunction, SwitchBotAirconControlFunction) have descriptions of adequate length (78-130 chars) but lack crucial parameter-level detail. Input schemas show types and basic descriptions but are incomplete: parameter descriptions are under 20 chars for critical fields (e.g., 'command' described only as 'Command value: ...'), making descriptions non-actionable for LLMs. No output schemas are documented. Tool naming violates verb_noun convention (should be control_switchbot_tv, not SwitchBotTVControlFunction). No error handling guidance or recovery paths. Tool definitions appear to be inferred from function class names rather than explicitly registered with complete schemas, triggering the inference penalty.

• Rename tools to follow verb_noun convention: control_switchbot_tv, control_switchbot_light, control_switchbot_aircon. This matches LLM expectations and makes tool intent immediately clear from the name alone.
• Expand parameter descriptions to 50-100 chars with explicit constraints. Example for 'commandType': 'The control action: power (turn on/off), channel (change to number 0-99), or volume (adjust by -3 to 3).' Include ranges and valid values inline in description text.
• Convert free-form string parameters to enums. For commandType, use enum=['power', 'channel', 'volume']. For command under power, use enum=['turnOn', 'turnOff']. This prevents hallucinated values and makes tool self-documenting.
• Document parameter dependencies explicitly. For SwitchBotTVControlFunction, note in description: 'commandType determines valid command values: if power, use turnOn/turnOff; if channel, provide 0-99; if volume, provide -3 to 3.'
• Document return schemas. Specify what each tool returns: e.g., 'Returns {status: success|error, device_state: {power: on|off, channel?: number, volume?: number}, timestamp: ISO8601}' so LLMs know what fields to expect.
• Add error recovery guidance. Instead of generic errors, return specific guidance: 'Temperature 30°C out of range. Valid range: 22-28°C. Retryable: yes' or 'Device offline. Last seen: 2024-01-15T10:30:00Z. Try again in 5 mins.'
• Mark all three tools as destructive (side-effect operations). Add note: 'This tool controls physical devices. Commands are executed immediately and cannot be undone. Verify intent before calling.'