Single tool with critical definition gaps. Tool name 'example_tool' is generic and lacks action verb (should be verb_noun pattern like 'process_message'). Description is minimal (47 chars, below 10-char baseline for meaningful context). Input schema present but lacks parameter descriptions, the 'message' parameter has no guidance on format, length, or constraints. No output schema documented. No error handling guidance. Tool appears to be a placeholder/template rather than production-ready.

• Rename 'example_tool' to a verb_noun pattern reflecting the actual operation, e.g., 'process_message', 'transform_text', or 'analyze_message'. This enables LLMs to infer intent from the name.
• Expand tool description to 80-150 chars. Include: (1) What it does, (2) When to use it vs. similar tools, (3) What it returns. Example: 'Processes and analyzes a text message, returning sentiment, key entities, and a summary. Use this to understand user intent before routing to specialized handlers.'
• Add description to the 'message' parameter: 'The text message to process (1-5000 chars, plain text or markdown). Supports multi-line input.'
• Document the output schema in code comments or a separate schema definition. Specify return type (string, object with fields), and what each field represents. Example: 'Returns {result: string, tokens_used: number, processing_time_ms: number}'.
• Add error handling: catch execution errors and return structured error responses with recovery hints. Example: 'Message too long (5001 chars). Max is 5000. Try splitting into smaller chunks and calling again.'