Three tools with basic verb-noun naming (get_*, apply_*) but significant quality gaps. All tools have descriptions (10-60 chars, below the 194-char baseline), but lack depth on WHEN to use them and prerequisites. Input schemas are present with type definitions, but parameter descriptions are minimal (5-20 chars vs 72-char baseline). No output schemas documented. No error handling guidance, responses are free-text strings, not structured objects. No pagination, no field-level documentation. Tool composition is reasonable (three separate concerns), but responses lack the IDs and metadata needed for chaining downstream calls.

• Expand tool descriptions to 100-200 chars. Include WHAT (action), WHEN (use case), and WHAT IT RETURNS (output format). E.g., 'Check remaining leave balance for an employee. Call this before apply_leave to verify sufficient days. Returns: employee_id, balance (int), last_updated (ISO date).'
• Add format and validation hints to parameter descriptions. E.g., 'employee_id (string, format: E001-E999, required): The unique employee identifier. Example: E001.'
• Return structured JSON objects instead of free-text strings. E.g., get_leave_balance should return {"employee_id": "E001", "balance": 18, "total_allocated": 20, "used": 2}. Document the output schema in the tool description.
• Add error recovery guidance. When employee_id is not found, return: 'Employee ID "E999" not found. Valid IDs: E001, E002, E003. Try a different ID or contact HR.' This enables LLM self-correction.
• Mark apply_leave as a WRITE operation in the description: 'Apply leave for specific dates. This operation is irreversible, it deducts days from the employee balance and records the dates in history. Verify the employee_id and dates before calling.'