Have Codex review code

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of disclosing side effects, and it does so clearly: 'Codex reviews read-only and changes nothing.' It also discloses the return behavior—a review task that can be polled or extended—which is important since there is no output schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three tight sentences with no filler. The core action is front-loaded, the primary use cases follow immediately, and the safety guarantee and return contract are packed into short, scannable statements.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations and no output schema, the description covers the essential operational context: read-only behavior, return format as a pollable task, and how to chain with codex_continue. It could slightly expand on what 'report findings' means or how results are retrieved, but the schema and sibling names make the overall workflow reasonably complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and all nine parameters have meaningful descriptions in the schema itself. The tool description adds context around parameters like taskId and model ('on a Codex task's output with a different model'), but the schema already does the heavy lifting for individual parameter meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Ask Codex to review changes and report findings.' It clearly positions the tool as a review action, distinct from the sibling tools that manage checkpoints, worktrees, or delegate tasks, and it explicitly notes the returned artifact is a pollable review task.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives concrete when-to-use guidance: use on your own work before shipping, or on a Codex task's output with a different model for a cross-model second opinion. It also tells the agent how to continue after the call by polling or extending with codex_continue, though it does not explicitly say when not to use this tool or name alternative review workflows.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.