Single tool 'ask_rishvan' has a clear verb-noun name and adequate description (89 chars), but critical gaps undermine quality. Input schema is visible with two required parameters (question, app_name), both typed as strings with descriptions. However, no output schema is documented, the tool's response structure is completely opaque to LLMs. The tool lacks error handling guidance, recovery instructions, and does not declare whether it is idempotent or has side effects. Risk classification is READ_ONLY but the tool actually creates persistent requests in a database (side effect not reflected). No parameter constraints (enums, ranges, formats) are specified. The description does not explain when to use this tool vs alternatives, what happens on timeout, or how the LLM should interpret the response.

• Document the complete output schema: {id: uint64, status: string ('pending'|'responded'), response: string|null, created_at: ISO8601, responded_at: ISO8601|null}. This enables LLMs to extract the response and plan next steps.
• Correct the risk classification from READ_ONLY to WRITE. Add idempotentHint: false and destructiveHint: false (or true if human response is irreversible). Explain that repeated calls with the same question create duplicate requests.
• Add error handling guidance to the description: 'If the human does not respond within 5 minutes, the request times out. Retry with a clearer question or escalate to a different human.' Include timeout behavior and recovery paths.
• Add parameter constraints: question (min 10, max 500 chars, required), app_name (min 1, max 100 chars, alphanumeric + hyphens, required). Use descriptions to state these bounds.
• Expand the tool description to 150-250 chars explaining: (1) What it does: 'Pauses the agent and asks a human for input via a web UI'; (2) When to use it: 'When the agent needs human judgment, approval, or clarification'; (3) What to expect: 'Returns the human's response text or null if timeout occurs.'