Four tools with minimal descriptions (20-60 chars) and single-parameter schemas. Tool names lack action verbs (orchestrate, summarizer, code_helper, extractor are nouns/adjectives). Descriptions are generic and do not explain WHEN to use each tool or what distinguishes them. No parameter descriptions beyond the input field itself. Output schemas are documented in code but not formally declared in tool registration. No error handling guidance, no enum constraints, no pagination support. Naming violates verb_noun convention, 'orchestrate' and 'summarizer' are vague; 'run_summarizer' or 'summarize_text' would be clearer. Single-string input design is overly simplistic for a task orchestrator.

• Rename tools to verb_noun pattern: 'orchestrate_task', 'summarize_text', 'help_with_code', 'extract_data'. This lets LLMs parse intent from the name alone.
• Expand descriptions to 50-200 chars. For each tool, state: WHAT it does, WHEN to use it (vs. other tools), and WHAT it returns. Example: 'Summarize text into a concise overview. Use when you need a brief summary of long content. Returns summary text and trace events.'
• Add descriptions to the 'task_text' parameter in all four tools. Example: 'The user task or instruction to process. For summarizer: the text to summarize. For code_helper: the code issue or error. For extractor: the text to extract structured data from.'
• Formally document output schemas in tool registration using Pydantic models or JSON Schema. Define return type with fields: tool_used (str), result_summary (str), trace (list of objects). This enables LLMs to plan multi-step workflows.
• Add error handling guidance: document what errors each tool can raise (e.g., 'LLM unavailable, tool not found, invalid input') and recovery steps. Example: 'If LLM is unavailable, orchestrate falls back to rule-based routing. If a tool is not found, check tool_registry.'