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

No annotations are provided, so the description carries the full burden of disclosing behavior. It states the core action and the preference-vs-context decision rule, but it does not disclose side effects such as whether answering finalizes the request, whether it can be called multiple times, or any permissions or rate limits. The 'Ask the user' line reads as guidance to the agent rather than a behavior of the tool itself.

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 two sentences with no filler; the core action is front-loaded and the decision rule is stated in the second sentence. It is compact and readable, though slightly terse in phrasing like 'all question IDs.'

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?

For a tool with a nested answers object, three required parameters, no annotations, and no output schema, the description covers the main action and the answer-content decision rule. It leaves open details such as threadId semantics, multi-string answer arrays, and postconditions, so an agent can call it correctly but with some uncertainty.

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?

With schema description coverage at 0%, the description must compensate; it does so by mapping 'requestId' and 'all question IDs' to identifiers in the schema. It does not clarify the role of threadId or explain why each answer value is an array of strings. This is partial compensation but not enough to fully document the parameters.

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 the specific verb 'Answer' with a clear resource (a Codex question) and identifies the required identifiers ('requestId' and 'all question IDs'). This distinguishes it from siblings like codex_start, codex_message, and codex_stop, which handle other phases of the Codex interaction. However, 'Codex question' is not deeply defined, so it stops short of a 5.

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 a conditional rule for content: 'Ask the user when the answer requires their preference; otherwise answer from the task context.' This tells the agent how to decide what to put in the answers, but it does not explicitly name alternatives or exclusions among sibling tools. The trigger ('Answer a Codex question') implies when the tool applies, but that is left to inference.

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

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

No annotations are provided, so the description carries the burden of behavioral disclosure. It reveals non-obvious behavior: the journal is bounded, and a 'gap' means older events were evicted. It also warns against busy-polling. It could add error/return details, but the eviction caveat is valuable.

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?

Three short sentences, each earning its place: the core read action, the eviction caveat, and the usage guidance. Information is front-loaded and free of filler.

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?

For a single-parameter, read-only journal tool with no output schema, the description covers the purpose, the eviction pitfall, and the intended use case. The only notable gaps are the exact return shape and behavior when `after` is omitted, but overall an agent has enough to call it correctly.

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 0%, so the description must compensate. It does by explaining that `after` is a sequence number representing the position in the event journal to read from. The schema only says integer; the description adds the domain meaning. It does not address what happens if `after` is omitted, but the core semantics are clear.

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 states a specific action and resource: 'Read the bounded event journal after a sequence number.' The qualifier 'bounded' and the recovery-use case make it clear this is the journal-read tool, distinct from the other codex_* action/status siblings.

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?

Explicitly states when to use the tool: 'Use to recover results if channel delivery is unavailable.' It also gives a clear prohibition: 'do not busy-poll.' This is strong usage guidance even without naming an alternative sibling.

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

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

With no annotations, the description carries the burden of behavioral disclosure, and it does reveal meaningful behavior: it can act on a running turn or start a new one when idle, and it can error due to a race with turn completion. It provides actionable retry guidance, though it does not say what the success response looks like or whether the call blocks until the turn finishes.

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?

Two sentences with no filler. The primary action is stated first, followed by the idle-thread behavior and the race-condition warning, all in an efficient, scannable structure.

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?

The core semantics and a key error condition are covered, but there is no output schema and no annotation to fill gaps about return values or lifecycle expectations. An agent would benefit from knowing what a successful response contains and how threadId relates to codex_start or codex_status, so the context is adequate but not comprehensive.

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%, so the description should compensate, but it only lightly does. 'Same thread' gives context to threadId, and 'send direction' hints at the message parameter's role. The parameter names and types are fairly self-explanatory, but the description does not clarify message content format, length expectations beyond schema, or how threadId should be obtained.

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 clearly states that the tool sends direction to a running Codex turn or starts a new turn in the same thread when idle. The action and target resource are identifiable, and the idle/running distinction adds precision, though it does not explicitly differentiate this tool from siblings like codex_start or codex_resume.

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 clear usage context: use it to direct a running turn, or to start another turn in the same idle thread. It also warns about a race with turn completion and advises inspecting status before retrying. It stops short of naming alternatives explicitly or saying when not to use this tool.

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

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

With no annotations, the description carries the behavioral disclosure burden. It clearly identifies the operation as a list and explicitly reveals cursor-based pagination via nextCursor. It does not mention side effects, but 'List' strongly implies a read-only operation and the pagination detail is meaningful disclosure.

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?

Two sentences, front-loaded with the core purpose, followed by the pagination instruction. No redundant content or filler.

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?

For a one-parameter list tool with no output schema, the description covers the essential behavior and pagination. It does not explicitly describe the response shape, but the name and 'list' semantics make the return value predictable enough. Slightly more detail about the first-page call would make it fully 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?

The schema only provides 'cursor' as a string; schema coverage is 0%. The description compensates by explaining that cursor should be set to the nextCursor value to fetch another page, which gives the agent exact semantic guidance for the only parameter.

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 'List' with a clear resource, 'available Codex models', which is distinct from the sibling operations (start, message, stop, etc.). The agent can immediately tell this tool is for enumerating models, not running a session.

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 intended use case is implied by the listing purpose, but the description does not explicitly say when to use this tool versus the sibling tools or provide any exclusions. It would benefit from a note such as 'use before codex_start to select a model.'

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

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

With no annotations, the description carries the behavioral burden and does meaningful work: it clarifies that resume does not itself continue the work, only attaches the thread, and that it depends on reconnection. Minor omissions such as idempotence or error behavior exist, but the key behavioral distinction from codex_message is disclosed.

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?

Two short sentences with no filler. The main action and the crucial routing hint are front-loaded, and every clause adds value.

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?

For a single-parameter, low-complexity tool, the description is complete enough: it states what it does, when to use it, and what to use instead for continuation. No output schema or annotation exists, but none is required for the agent to select and invoke the tool correctly.

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 0%, so the description must compensate for the lone threadId parameter. It adds the meaning 'a saved Codex thread,' which helps, but it does not explain where the threadId comes from or what qualifies as saved. This is partial compensation rather than full.

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 ('Attach') and resource ('a saved Codex thread'), and explicitly contrasts with codex_message ('to continue its work'). This clearly tells an agent what codex_resume does and how it differs from the sibling that continues work.

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?

It states the condition ('after reconnecting'), the action ('attach a saved Codex thread'), and the alternative ('Use codex_message to continue its work'). An agent receives explicit routing guidance without needing to infer.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals important traits: full filesystem/network access, no approval prompts, and immediate return of the threadId after acceptance. It does not detail asynchronous execution or post-start behavior, but the disclosed runtime privileges are highly relevant and go well beyond the tool name.

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?

Two sentences with no filler. The core action and return value are front-loaded, and the second sentence adds the essential behavioral warning about permissions and the expected input strategy. Every clause earns its place.

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, an output schema, and only three parameters, the description covers the key information needed to call the tool correctly: required inputs, optional model, return value, and significant runtime behavior. It could mention how to interact with the returned threadId via sibling tools, but that is not necessary for a correct first call.

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 0%, so the description must compensate. It maps cwd to 'absolute working directory' and prompt to 'complete task context', which adds real meaning over the raw schema. It also explicitly notes that model is optional. It does not enumerate model choices, but the sibling tool codex_models likely covers that.

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: 'Start a live Codex agent' and states it returns a threadId after acceptance. This clearly distinguishes the tool from siblings like codex_message, codex_stop, and codex_status, which operate on an already-started agent.

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 clear context for when to use the tool: to start a live Codex agent. It also instructs the caller to supply an absolute working directory and complete task context, and notes that model is optional. It does not explicitly list alternatives or when-not-to-use, but the verb 'start' and sibling names make the intended usage fairly clear.

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

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

No annotations are provided, so the description carries the behavioral disclosure burden. It states that this is a read operation and that it does not wait for completion, which is useful. It does not cover prerequisites, error conditions, or whether an active session is required, but the most important non-mutating, non-blocking traits are disclosed.

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?

Three short sentences each add distinct value: what is read, how to use the optional threadId, and the non-blocking behavior. There is no wasted wording or repetition of schema information.

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?

For a simple one-parameter read tool, the description covers the main invocation modes: all sessions or a specific thread. It also clarifies the non-waiting behavior. Since there is no output schema, a little more detail about the return shape would help, but the essential information for using the tool is present.

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?

The schema only defines threadId as an optional string. The description adds meaning by explaining that omitting threadId lists sessions, which implicitly defines the parameter's behavior. It doesn't explicitly say 'supply threadId to read one session,' but this is strongly implied by the structure.

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 clearly identifies a read operation ('Read') and a specific resource: session state, pending questions, and the latest answer. This distinguishes it from action-oriented siblings like codex_start, codex_message, and codex_stop. The broader scope also differentiates it from codex_answer, so an agent can reliably understand what this tool is for.

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?

It gives one concrete usage rule: 'Omit threadId to list sessions.' However, it doesn't explicitly say when to prefer this tool over siblings like codex_answer or codex_events, nor does it name alternatives. The usage context is implied rather than fully stated.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds important non-obvious details: the interruption is confirmed by an event, and the operation does not undo changes already made. It could mention error or no-op behavior, but the key consequences are disclosed.

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 two sentences with no filler. The action is front-loaded, and the most important behavioral caveat is stated immediately.

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?

For a low-complexity tool with a single parameter and no output schema, the description covers the core purpose, the confirmation mechanism, and the non-rollback behavior. It does not cover edge cases such as no active turn, but overall it is sufficiently complete for an agent to invoke it correctly.

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?

The schema provides only a required threadId string with no description, and the tool description does not explain the parameter beyond the context of a running Codex turn. However, threadId is self-descriptive and clearly maps to the target turn, so the meaning is reasonably recoverable.

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 states a specific action ('Request interruption') targeting a resource ('a running Codex turn') and is clearly distinct from siblings like codex_start, codex_resume, and codex_status. It is immediately obvious what this tool does.

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 tool is for stopping an already-running turn, but it does not explicitly state when to use it, when not to use it, or how it relates to alternatives. There is no mention of checking codex_status first or waiting for natural completion.

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