Single tool 'run' has a clear action verb and acceptable description (89 chars), but critical gaps undermine quality. Input schema is present with three parameters (task, stallTimeoutMs, maxRecoveryAttempts), all with type and description. However, parameter descriptions lack actionable constraints: stallTimeoutMs and maxRecoveryAttempts state defaults but no min/max bounds, range validation, or format guidance. No output schema is documented, the tool returns EventProcessingResult with items, threadId, finalResponse, usage, stalled, error fields, but this structure is never exposed to the LLM. Error handling is internal (stall detection, recovery attempts) but not surfaced as tool-level error guidance. The tool performs a complex, stateful operation (Codex task execution with recovery) but the description does not clarify what 'stalled' means, when recovery triggers, or what the LLM should do if the tool fails. No idempotency guarantee stated. Risk marked WRITE but no confirmation/dry-run pattern offered for such a destructive operation.

• Document the complete output schema: return type should specify {items: ThreadItem[], threadId: string|null, finalResponse: string, usage: {input_tokens: number, output_tokens: number}|null, stalled: boolean, error?: string}. Include field descriptions and when each is populated.
• Add explicit constraints to numeric parameters: stallTimeoutMs (min: 1000, max: 3600000, default: 300000), maxRecoveryAttempts (min: 0, max: 10, default: 2). State units clearly ('milliseconds', 'attempts').
• Enhance tool description to explain: (1) What 'stall detection' means (no event received for N ms), (2) When recovery is attempted and what it does, (3) What the LLM should do if stalled=true or error is set, (4) Whether the operation is idempotent or has side effects.
• Add error classification and recovery guidance: return errors as {code: string, message: string, retryable: boolean, nextSteps: string}. E.g., 'stall_timeout: No activity for 5 minutes. Retry with increased stallTimeoutMs or check Codex service status.'
• Implement a confirmation pattern for destructive operations: add an optional 'dryRun' parameter (default: false) or a separate 'preview_task' tool that shows what the task would do without executing it.