All 13 tools share identical, severely deficient schemas and descriptions. Each tool has a generic 1-line description (10-30 chars, well below the 50-200 char baseline for LLM-optimized descriptions) and a single string parameter 'input' with minimal context. No parameter descriptions explain what the input JSON should contain, no output schemas are documented, and no error handling guidance is provided. Tool names lack action verbs (e.g., 'performance_review' instead of 'generate_performance_review'). The implementation treats all tools as generic pass-throughs to a remote Bankr API, offering no validation, no field-level documentation, and no composition support. This pattern violates 40+ of the 54 Agentic Tool Patterns.

• Rename all tools with action verbs: 'performance_review' → 'generate_performance_review', 'compensation_benchmark' → 'calculate_compensation_benchmark', etc. This enables LLMs to infer intent from the name alone.
• Expand each tool description to 80-150 characters. Example: 'Generate a performance review for an employee. Requires: employee_id, review_period (YYYY-MM), rating_scale (1-5). Returns: review_text, rating, recommendations.' This answers WHAT, WHEN, and WHAT-RETURNS.
• Replace the generic 'input' string parameter with explicit, typed parameters. Example for performance_review: {employee_id: string, review_period: string (YYYY-MM), rating_scale: enum [1,2,3,4,5]}. Add descriptions to each parameter explaining constraints and format.
• Document output schemas for each tool. Example: 'Returns: {review_text: string, rating: number (1-5), recommendations: string[], generated_at: ISO8601}'. This enables LLMs to chain tools and extract data reliably.
• Add error handling with recovery guidance. Catch API errors and return: {status: 'error', error: 'User not found', recovery: 'Call search_employees() with partial name first'}. Categorize errors as retryable vs. user-fixable.