All 5 tools have minimal, generic descriptions (10-30 chars) that fail to explain WHAT the tool does, WHEN to use it, or what it returns. Input schemas are present but trivial: all tools accept a single 'input' string parameter with no type validation, format guidance, or constraints. No output schemas documented. No error handling guidance. Tools lack verb-based naming (e.g., 'contract_generator' vs 'generate_contract'). No parameter descriptions beyond 'Input data (JSON)'. No indication of idempotency, side effects, or prerequisites. Descriptions fall well below the 50-200 char baseline for LLM-optimized tools and lack actionable context.

• Rename tools to verb_noun form: 'generate_contract', 'generate_nda', 'translate_document', 'extract_document_text', 'analyze_safety_data_sheet'. This lets LLMs infer action intent from the name.
• Expand each tool description to 80-150 characters explaining WHAT it does, WHEN to use it, and what it returns. Example: 'Generate a legal contract from structured input (company name, parties, terms). Returns contract text and metadata. Use when you need to create a new agreement.'
• Replace the generic 'input' parameter with specific, typed parameters. For contract_generator: accept 'company_name' (string), 'parties' (array of strings), 'contract_type' (enum: service|nda|employment), 'terms' (object with duration, payment, etc.). Document each parameter's format and constraints.
• Document output schemas for each tool. Example for generate_contract: {contract_text: string, contract_type: string, generated_at: ISO8601, status: 'success'|'error'}. This enables LLMs to extract and chain results.
• Add error handling guidance to descriptions: 'If the Bankr API returns an error, the tool will return {status: "error", error: "<message>"}. Common errors: invalid_input (check parameter format), rate_limit (retry after 60s), service_unavailable (retry with exponential backoff).' This guides LLM recovery.