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

Annotations declare readOnlyHint=false and openWorldHint=true, but the description adds substantial non-obvious context: prompt/context/target_files are sent to OpenAI, each run spends the user's own Codex usage, the user must be told when delegating, and the default sandbox is read-only unless reconfigured. This is exactly the kind of disclosure structured fields cannot carry.

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 core purpose and usage trigger are front-loaded, and for a 17-parameter tool the length is defensible. It is a dense single block with some redundancy (the 'Codex cannot see this conversation' constraint is echoed by the schema), but each sentence carries operational weight.

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 high-complexity tool with 17 parameters, no output schema, and a nested output_schema parameter, the description covers delegation conditions, privacy, cost, sandbox behavior, and the recommendation handoff. Return behavior (job_id for background, structured output block) is left to schema descriptions rather than explained, which is the main remaining gap.

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 100%, so the baseline is 3, but the description adds real meaning beyond the schema: the model parameter is tied to a codex_recommend workflow, sandbox read-only is the default and workspace-write is required for edits, and target_files/context/prompt are flagged as externally transmitted. This lifts it above the schema-only baseline.

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?

States a specific verb (delegate) and resource (a task to the local Codex CLI, described as OpenAI's coding agent), with additional scoping that distinguishes it from siblings by naming codex_recommend as the prerequisite recommendation tool. An agent can tell exactly what this does and how it differs from list_codex_models and codex_recommend.

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?

Gives explicit when-to-use triggers ('when the user asks for Codex, or when handing work off clearly serves their request: a second opinion from a different model family, or an investigation that would otherwise flood this conversation') and an explicit when-not ('do not delegate what you can answer directly'). It also names the alternative workflow (codex_recommend first when no model is chosen), leaving nothing 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?

The annotations already declare readOnlyHint=true and openWorldHint=false, and the description's 'never installs or changes anything' reinforces that safety profile without contradicting it. It adds useful behavioral scope by explaining the inspection covers signed-in state and configuration loading, and that it emits remediation steps rather than performing fixes. It doesn't detail the exact return format or mention the cached diagnosis behavior described in the refresh parameter, but the schema covers that.

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 sentences, no fluff, and the most decision-relevant facts come first: what it checks, when to run it, and what it will not do. Every sentence earns its place, and the coverage of purpose, usage, and safety is achieved in extremely compact form.

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 zero-required-parameter diagnostic tool, the definition is complete: it states the checks performed, what the output will contain (fix steps), when to invoke it, and that it is read-only. The schema covers the two optional parameters, and the annotations cover the side-effect profile, so nothing needed for correct selection or invocation is missing.

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 both parameters already have strong descriptions: refresh explains the cache/re-probe behavior)Skip and working_dir explains the directory-sensitive configuration loading and its default. The tool description contributes contextual motivation by tying the check to delegation, but it does not add meaning beyond what the schema already provides. A baseline 3 is appropriate because the schema carries the parameter documentation burden.

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 names a specific verb ('check') and a concrete resource (the local Codex CLI installation), then elaborates with four concrete checks: installed, recent enough, signed in, and able to load configuration. It also states the actual outcome ('report the exact steps to fix it'), which differentiates this diagnostic tool from the delegation, recommendation, and job-management 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?

It gives explicit trigger conditions: run when another tool reports the CLI is unavailable, or before relying on delegation for the first time. It also states a clear exclusion—it only inspects and never installs or changes anything—so an agent knows not to use it as a fixer and should look elsewhere for remediation.

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?

Annotations only declare readOnlyHint=false and openWorldHint=true, so the description carries the rest: the call goes to OpenAI, spends the user's Codex usage, and the thread is stateful (earlier context is reused). That is meaningful disclosure beyond structured fields, though sync/async behavior is left unstated.

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, front-loaded with who/what/how, followed by the stateful-context point and then the cost warning. No 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 9-parameter, stateful, externally-billed call with no output schema, the description covers the essentials: thread linkage, context reuse, and cost. It omits whether the call blocks or returns a job handle (relevant given codex_job_status/codex_job_result siblings), which is the main remaining gap.

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 89%, which already sets a baseline of 3, and the description genuinely adds prompt semantics: Codex retains earlier context, so only the new instruction needs to be sent. That is meaning beyond the schema's 'The follow-up instruction.'

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?

States a specific verb (send a follow-up message) plus the exact resource and linking key (a previous delegation, via its thread_id). The phrase 'previous delegation' implicitly separates it from codex_delegate, which starts a new one, so an agent can route correctly without opening either schema.

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?

'Send a follow-up ... using its thread_id' implies the precondition (you must already hold a thread_id from codex_delegate), and the cost sentence signals weight. However, no alternative is named and no explicit when-not condition is given, so usage is inferred rather than 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?

Annotations already declare destructiveHint=true and readOnlyHint=false, clearly indicating a destructive operation. The description adds 'running' as a state constraint, which is useful. However, it omits key behavioral details like whether the job is killed immediately or gracefully, whether it can be undone, or what happens to any partial results. With annotations covering the safety profile, a 3 is appropriate.

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, efficient sentence with no wasted words. It is front-loaded with the action, though it is extremely terse, which might leave some ambiguity.

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 the tool's simplicity (one parameter, no output schema) and the annotations covering destructiveness, the description is minimally adequate but lacks important context about side effects, job state requirements, and the return value or confirmation. It should do more to help an agent understand when and how to use it safely.

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%, so the single parameter job_id is fully documented in the schema, including that it comes from codex_delegate. The description adds no additional parameter meaning beyond what the schema provides, making the baseline 3 correct.

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?

States a specific verb (Terminate) and resource (running background delegation), which is clearer than the title. However, it does not distinguish itself from siblings like codex_job_status or codex_job_result, so it falls 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?

There is no guidance on when to use this tool versus alternatives, or when not to use it. The description gives no context about the conditions under which cancellation is appropriate, such as whether the job must be running or what happens if it has already completed.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds a meaningful behavioral constraint: it errors when the job is still running, telling the agent this is a post-completion read with a specific failure mode. It does not discuss output truncation or pagination, so 4.

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, zero waste, and the completion precondition is front-loaded. The error condition follows immediately after the main action, keeping the most important routing information prominent.

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 tool with full schema coverage and annotations covering safety, the description supplies the necessary completion precondition and output scope. No output schema exists, so describing the return as 'full output' is appropriately 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 the only parameter 'job_id' is documented as 'returned by codex_delegate'. The description adds no additional syntax, format, or constraint beyond the schema, so the baseline of 3 applies.

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?

States a specific verb ('Return') and resource ('full output of a finished background delegation'), and the error condition distinguishes it from a status check. It does not explicitly name sibling codex_job_status as the alternative, so it falls 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?

Implies use only after completion via 'finished background delegation' and 'Errors if the job is still running'. However, it does not explicitly tell the agent to call codex_job_status first or name alternatives, so usage is inferable but not spelled out.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds that it reports state plus recent activity and that omitting job_id enumerates all jobs, but says nothing about pagination, log volume, or failure modes for unknown job ids.

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, front-loaded with the core purpose and with the no-arg listing behavior second; no 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 zero-required-param, read-only status tool with no output schema, the description covers what is queried (state and activity) and the two calling modes. It is nearly complete, with only return-shape hints and error handling left unspecified.

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 both parameters are already documented in the schema; the description's note about omitting job_id restates that documentation rather than adding format or constraint detail.

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?

States a specific verb (report) plus resource (state and recent activity of a background delegation) and scopes it to delegations started with mode=background, which links it to codex_delegate and separates it from codex_job_result.

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 — call with no job_id to list every known job — but never says when to prefer this over codex_job_result, codex_follow_up, or codex_job_cancel, so the sibling routing 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?

Beyond the readOnlyHint and openWorldHint annotations, the description discloses that the tool executes no model call and applies a documented matrix reconciled against the installed catalog. This adds meaningful context about how the recommendation is derived (deterministically, not by running a model) without conflicting with the annotations.

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 two-sentence description is compact and front-loaded: it immediately states the input ('Given a task description') and the output ('recommend which Codex model and reasoning effort'). The second sentence clarifies a key behavioral trait without waste. Every sentence 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?

For a simple tool with 3 parameters (1 required) and no output schema, the description is adequately complete. It specifies the recommendation output (model and effort) but does not detail the exact return structure (e.g., object or string). Given the low complexity and clear sibling context (codex_delegate, list_codex_models), this is sufficient.

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?

All three parameters are fully described in the input schema (100% coverage), so the description adds no parameter-specific detail beyond the schema. With full schema coverage, the baseline of 3 is appropriate; the description does not compensate with extra parameter guidance.

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 verb and resource: 'recommend which Codex model and reasoning effort to delegate it with.' It also notes 'Runs no model call,' which clearly differentiates this advisory tool from execution tools like codex_delegate. The purpose is unambiguous and distinct from 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?

The description implies usage ('Given a task description... recommend') but does not explicitly say when to use this tool versus alternatives like codex_delegate or list_codex_models. The phrase 'Runs no model call' hints it is not for execution, but there is no explicit 'Use this before delegating' or 'For execution, use codex_delegate.' Guidance is implied, not 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?

Annotations already mark the tool read-only, and the description adds useful behavioral context: it reads from the installed Codex CLI and has a 'warned static fallback' if the catalog cannot be read. This goes beyond the annotation in a meaningful way, though caching behavior is left to the 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?

Three sentences, each earning its place: the core purpose, the fallback behavior, and the usage guidance. It is front-loaded with the essential information and contains no 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 simple read-only listing tool, the description covers the key context: what is listed, where it is read from, the fallback behavior, and when to call it. It does not describe the return format, but no output schema exists and the purpose makes the return shape largely predictable.

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%, so the schema fully documents both parameters. The description does not add parameter-level meaning beyond the schema, which makes the baseline 3 appropriate.

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 names a specific action ('List'), a precise resource ('Codex models available on this machine'), and additional detail ('reasoning-effort levels each one supports'). It also distinguishes itself from a sibling by pointing to codex_delegate, so an agent can tell why this tool exists.

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 explicit usage context: 'Call this before codex_delegate when choosing a model explicitly.' It clearly states when the tool should be used, though it does not name alternatives to avoid or describe when not to use it.

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