ProofAgent Harness defines 5 tools with clear names and reasonable descriptions (avg 95 chars). All tools have input schemas with required fields and type definitions. However, parameter descriptions are sparse or missing entirely, most params lack guidance on format, constraints, or valid values. Output schemas are not documented. Error handling is minimal; no recovery guidance or actionable error messages visible. The tools follow a logical composition (verify → lookup → check → refund), but lack the depth expected of production-grade agent tools. No tool annotations (readOnlyHint/destructiveHint) despite clear risk profiles (4 READ_ONLY, 1 WRITE).

• Add parameter descriptions to all tools. For 'booking_ref': 'A 6-character alphanumeric booking reference (e.g., ABC123). Case-insensitive.' For 'amount': 'USD amount to refund (0.01 - 10000.00). Must not exceed original booking amount.'
• Document output schemas for each tool. E.g., verify_identity returns {verified: boolean, passenger_name: string, error?: string}. lookup_booking returns {booking_ref: string, fare_class: string, amount: number, booked_date: string}.
• Add tool annotations: mark issue_refund with destructiveHint=true and idempotentHint=false (refunds are not idempotent). Mark verify_identity and lookup_booking with readOnlyHint=true.
• Define error responses with actionable guidance. E.g., 'Booking not found: ABC123. Verify the reference is correct (6 chars, alphanumeric).' instead of a bare 404.
• Add constraints to 'reason' parameter in escalate_to_human: 'A brief explanation (10 - 500 chars) of why this request requires human review. Include the customer's concern and any policy rule that applies.'