codex_steer

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

No annotations are provided, so the description carries the full responsibility for behavioral disclosure. It does add one useful guarantee: it will not change sandbox or approval policy. However, it does not disclose whether the prompt is appended or replaces existing instructions, whether multiple calls are allowed, or what effect it has on already-generated content.

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 a single sentence that front-loads the core action and scope, then adds a valuable non-effect. There is no filler, redundancy, or unnecessary detail.

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 output schema, no annotations, and zero schema description coverage, the description is too sparse. It explains the general purpose and one non-effect, but it omits explicit parameter mapping, when-to-use guidance, and behavioral side effects. An agent can guess, but it is not fully equipped to call this tool correctly without further documentation.

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 coverage is 0% and the description does not explicitly explain the parameters. It hints that prompt is the instruction and jobId refers to the running turn, but it never names them or describes expected formats or behaviors. The parameter names are self-explanatory, yet the description adds no explicit value beyond the JSON Schema.

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 uses a specific verb and resource: '补充指令' (supplement instructions) to the '当前运行中的普通 Codex turn' (currently running normal Codex turn). It also distinguishes itself from siblings by scoping to normal running turns and explicitly noting it does not change sandbox/approval policy. An agent can separate this from codex_start, codex_cancel, codex_review, and the input-related tools.

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 implies the use case: add instructions to an already running Codex turn. However, it does not explicitly state when not to use it or name alternatives, such as codex_pending_input or codex_answer_input for turns awaiting input. The routing is left to inference, not explicit guidance.

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