Six tools with complete input schemas and descriptions present. Naming follows verb_noun convention (notify, ask, confirm, usage, sense, await_physical_event). Descriptions range 60-180 chars, meeting the 10-1024 baseline. However, parameter descriptions are minimal (5-20 chars), and output schemas are entirely undocumented. No error handling guidance, no recovery paths, and no indication of which operations are idempotent or destructive. The 'await_physical_event' tool lacks timeout validation constraints. Missing documentation of what fields are returned and how downstream tools should chain results.

• Document output schemas for all six tools. Specify exact field names, types, and ranges. E.g., 'ask returns {choice_index: int (0-3), choice_text: string}' and 'sense returns {battery_percent: int (0-100), accel_x: float, accel_y: float, accel_z: float, gyro_x: float, gyro_y: float, gyro_z: float}'.
• Expand parameter descriptions to 50-100 chars with format and constraint details. E.g., 'timeout_s: Maximum seconds to wait for an event (1-300, default 30). Returns immediately if event occurs sooner.'
• Add error handling guidance to tool descriptions. E.g., 'notify: Displays a banner on the Cardputer. If device is disconnected, returns error 'device_unavailable', retry after 30s or ask user to check device power.'
• Annotate tools with destructiveness and idempotency hints. Mark 'notify' and 'confirm' as potentially destructive (they consume user attention); mark 'sense' and 'usage' as read-only and idempotent.
• Document tool composition chains. E.g., 'ask returns choice_index; pass it to notify as context. sense returns battery_percent; use it to decide whether to prompt user for action.'