Single tool 'route_default' has a minimal description (58 chars) and basic input schema. The tool name lacks a clear action verb (should be 'run_route' or 'execute_route'). Input schema defines only 'prompt' with a string type and description, but lacks output schema documentation. No error handling guidance, no parameter constraints, and no indication of what the tool returns or when to use it. The description does not explain prerequisites, expected output format, or recovery paths for failures. This falls well below production baselines (avg tool description 194 chars, avg params 4 with full type+description coverage).

• Rename tool to 'execute_route' or 'run_aegis_route' to start with a clear action verb. This helps LLMs parse intent from the name alone.
• Expand description to 150 - 250 chars: explain what the Aegis pipeline does, when to call it (e.g., 'Use this to run security/policy checks on user prompts'), what it returns (e.g., 'Returns a decision object with allowed/blocked status and reason'), and any prerequisites (e.g., 'Requires a valid Aegis route configuration').
• Document the output schema explicitly. Include field names, types, and descriptions (e.g., 'Returns {decision: string (allowed|blocked), reason: string, score: number}'). This enables LLMs to extract and chain results.
• Add parameter constraints to 'prompt': specify min/max length (e.g., '1 - 10000 characters'), and clarify format (e.g., 'Plain text or markdown'). Include a note: 'If validation fails, the tool returns a 400 error with the constraint violated.'
• Add error handling guidance: 'If the pipeline times out (>30s), retry with a shorter prompt. If blocked due to policy, the reason field explains which policy triggered the block.'