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

The description adds meaningful behavioral context beyond the readOnlyHint annotation by listing exactly what the tool inspects and reports, including liveness checks and desktop/macOS integration details. It does not contradict the annotations, and for a read-only status tool the disclosure of its reported fields is sufficient.

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 immediately states the tool's purpose and then lists the specific items reported, with no redundant phrases or filler. Every clause adds information, and the structure is easy to parse for an agent.

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 zero-parameter status tool with readOnlyHint and openWorldHint annotations, the description is complete: it explains what the tool does, what information it exposes, and how it is bounded to the current machine. There is no output schema, so the enumerated report contents compensate appropriately and give the agent a clear model of the return value.

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 tool has zero parameters, and the schema coverage is 100% by definition, so there is no parameter semantics to clarify. Per the baseline for zero-parameter tools, this is a solid score; the description accurately describes the tool's fixed scope without pretending there are configurable inputs.

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 ('Report') and a specific resource ('how this bridge is wired on the current machine'), then enumerates the concrete facts returned: platform, resolved codex binary, app-server endpoint and liveness, deep-link support, and macOS integrations. This clearly distinguishes it from the sibling tools, all of which are imperative actions rather than status checks.

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 phrase 'Report how this bridge is wired' implies this is a diagnostic/status tool to be used when the agent needs environment or connectivity information. However, there is no explicit guidance about when to prefer this over the sibling tools, such as 'check this before delegating' or 'use this when an operation fails.' The usage context is clear but only 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?

With annotations already covering destructiveHint/openWorldHint, the description adds genuine behavioral context: the operation returns Codex's reply, hands the session to Codex Desktop, and specifically avoids leaving the bridge writer lock behind. This discloses a side-effect and cleanup detail that annotations cannot convey. No contradiction 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?

One dense sentence with zero filler: every clause carries one phase of the operation, and the distinctive lock-cleanup behavior is placed last for emphasis without bloating the description.

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 an 8-parameter destructive tool with no output schema, the description captures the main flow but omits the return shape; the timeoutSec parameter reveals that a threadId is returned on timeout, but the description only says 'return Codex's reply'. An agent knows what the tool does but not precisely what it gets back or how the desktop handoff interacts with the timeout case.

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, and the description only loosely reinforces cwd (project directory), name (named session), and prompt. It adds nothing about model, timeoutSec, or releaseAfterTurn beyond what the schema already documents.

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 precise verb chain (create session, send prompt, return reply, hand to Desktop) with a specific resource (a new Codex session at a project directory). This clearly differentiates it from send_to_codex_thread, which implies messaging an existing thread, without needing to open the 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?

Usage is implied rather than stated: creating a fresh named session and handing it to Desktop suggests delegation of work to a new Codex context. However, the description never explicitly says when to choose this over sending to an existing thread, nor does it name alternatives or exclusions.

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 destructiveHint=true and readOnlyHint=false, so the description carries a lower burden. It adds the useful condition that the turn must be still running, but it does not disclose side effects such as whether partial output is lost or whether the thread remains usable after interruption.

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?

A single, front-loaded sentence with no redundant content. It conveys the action, target, and condition in twelve words, making it highly efficient and easy to parse.

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 two-parameter tool with full schema coverage and annotations covering the destructive and idempotent nature, the description captures the core action and the key condition (still running). It lacks only minor detail about post-interruption behavior, which is not essential for correct invocation.

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 have clear descriptions in the schema (turnId is reported by send_to_codex_thread, threadId is the Codex thread id). The description adds no additional parameter-level meaning, so the baseline of 3 is 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?

States a specific verb ('Stop') and resource ('a turn ... in a Codex thread'), clearly distinguishing it from sibling tools that operate on threads or the app server. The qualifying phrase 'still running' further narrows the scope and makes the purpose unambiguous.

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 phrase 'still running' implies the intended use case—interrupting an active turn—but the description provides no explicit guidance on when not to use it or how it relates to alternatives like stop_codex_app_server. No when-to-use or when-not-to-use conditions are 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 provide readOnlyHint=true and openWorldHint=true, so this is clearly a non-destructive operation. The description adds value by specifying the exact output fields and its purpose, which is especially useful since no output schema is present. It does not describe sorting or the exact source scope, but the annotations lower the bar for side-effect 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?

The description is a single sentence that front-loads the verb, resource, and output fields, then states the practical purpose. There is no redundant filler or repetition of schema content.

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 list tool with a fully described schema and no required parameters, the description is nearly complete: it names the output fields and the intended follow-up action. It could be slightly more explicit about whether it lists only app-server-loaded threads or all persistent threads, but the loadedOnly parameter and sibling context make this a minor 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 description coverage is 100% and every parameter (cwd, limit, loadedOnly, searchTerm) already has a meaningful description, including the default limit of 15. The description adds no additional parameter-level meaning, so the baseline of 3 is 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 states a specific verb-resource pair ('List recent Codex threads') and enumerates the returned fields (id, title, cwd, last update, status). It also gives a clear goal — picking the exact threadId to talk to — which distinguishes this read-only listing tool from sibling action 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 when to use the tool: before interacting with a thread, when the agent needs to resolve a threadId. It does not explicitly name sibling alternatives or state when not to use it, so it stops short of a 5.

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 annotations (idempotent, non-destructive), the description adds platform scope, the URI scheme, and the UI-focus side effect. It does not cover failure behavior such as an invalid thread ID or the desktop app not running, but there is no contradiction 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?

Single sentence that front-loads the action and resource, then gives the purpose. No filler and no repetition of schema details.

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 description plus schema adequately cover the key call details for a low-complexity UI-focus operation. It does not explicitly state return or error behavior, but no output schema exists and the intent is clear, leaving only a minor 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. The description adds extra value by showing the exact codex://threads/<id> format for threadId, helping the agent construct a valid call beyond the schema's simple 'Codex thread id'.

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 action ('bring... to the front'), a specific resource (Codex thread), platform scope (Windows/macOS), and mechanism (codex://threads/<id>). This clearly distinguishes it from siblings like read_codex_thread or send_to_codex_thread.

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 conveys when to choose this tool: when a human should watch the work live instead of reading a transcript. It does not explicitly name alternatives or exclusion criteria, but the contextual purpose is clear enough for an agent to route correctly.

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 readOnlyHint annotation already covers the safety profile, and the description adds useful domain-specific context by stating that it sends nothing to the thread. This meaningfully clarifies that the tool is non-participatory, not merely read-only at the data layer. It does not describe the return format, but that is a smaller gap given 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 description is a single, front-loaded sentence with no filler. It immediately states the action, the target, and the key non-sending behavior.

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 tool with two well-documented parameters and a readOnlyHint annotation, the description is largely sufficient. It is missing explicit guidance about how the returned conversation is shaped and when open_codex_thread would be a better choice, but these are minor completeness gaps.

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%, with clear descriptions for threadId and limit including default and bounds. The tool description itself adds no parameter-specific meaning beyond 'recent conversation,' which aligns with the limit parameter. Baseline of 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 uses a specific verb ('Read'), a specific resource ('recent conversation of a Codex thread'), and adds a meaningful qualifier ('without sending anything') that differentiates it from send_to_codex_thread. It does not explicitly distinguish it from open_codex_thread, 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 phrase 'without sending anything' implies the tool is for passive, non-mutating inspection of a thread, which gives some usage context. However, the description does not explicitly state when to use this tool versus open_codex_thread, list_codex_threads, or other siblings, nor does it name alternatives.

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 declare destructiveHint=true and readOnlyHint=false. The description adds meaningful behavioral context: it waits for Codex to answer, preserves thread history/cwd/model, warns against closing the task, and explains the timeout behavior. It also details desktop delivery constraints and repair steps. This goes beyond the annotations without contradiction.

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 moderately long but every sentence contributes: it states the action, gives usage guidance, lists constraints, and provides an error-handling path. It is front-loaded with the primary purpose and structured logically. It is not overly verbose, though it could be trimmed slightly without losing meaning.

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 9 parameters and no output schema, the description covers usage, constraints, and error handling. It does not explicitly describe the return format, but the phrase 'wait for Codex to answer' implies the answer is returned. The description also addresses edge cases like desktop delivery and timeouts. The only minor gap is the lack of an explicit return type, but this is likely inferred.

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. The description adds value by explaining that threadId comes from list_codex_threads, that cwd and model are overrides for the thread's defaults (since the thread keeps its own), and that timeoutSec is capped at 40s on Desktop with the task continuing. It does not explain releaseAfterTurn, but the parameter name and schema description cover it. Overall, it enhances parameter understanding beyond the 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 states a specific action ('send a prompt as a new user turn inside an existing Codex thread'), identifies the resource (prompt) and the destination (existing thread), and implicitly distinguishes from siblings by emphasizing 'existing' and pointing to list_codex_threads for threadId discovery. It is clear and unambiguous.

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 explicitly instructs to use list_codex_threads when threadId is unknown, specifies the condition for Desktop-owned tasks (must use native delivery), and gives a fallback action when legacy delivery reports an active writer (inspect codex_bridge_status). This provides clear when-to-use and when-not-to-use guidance with alternatives.

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, readOnlyHint=false, and idempotentHint=false. The description adds useful behavioral context by mentioning atomic task creation, visible task assignment, and the fact that this tool does not wait for the reply, which is a meaningful behavioral distinction from its sibling.

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 deliver the core purpose and the most important usage distinction without filler. The main action is front-loaded, and the sibling routing guidance is efficiently integrated.

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 straightforward purpose, the description plus rich schema and annotations provide enough context to invoke it correctly. It does not describe the return value or non-Desktop mode behavior explicitly, but the sibling list and schema fill most practical gaps.

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 schema already documents each parameter including cwd, name, model, and prompt. The description adds only a small amount of context tying the prompt to Desktop-mode task creation, but it does not meaningfully expand on the schema's own parameter descriptions.

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 the tool 'Start a Codex task' with a specific verb and resource, and the title reinforces that it creates a new thread. It also distinguishes itself from delegate_to_codex by noting that the delegate variant additionally waits for the reply.

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 context for Desktop mode, telling the agent to include the initial prompt when creating a visible task atomically. It also names delegate_to_codex as the alternative when waiting for a reply, though it does not enumerate all other sibling alternatives or explicitly state non-Desktop mode behavior.

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 signal idempotent and destructive, and the description adds meaningful context beyond them: the shared-server scope, the stuttering problem it prevents, and automatic restart by the bridge on next use. It does not detail effects on in-flight Codex threads, but 'when work is handed off' and the auto-start note cover the main behavioral concerns.

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: what it stops, when to use it and why, and what happens next. The key trigger is front-loaded after the opening statement.

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-parameter, no-output-schema tool, the description covers purpose, trigger conditions, rationale, and post-call behavior. The sibling context and annotations complete the picture without requiring extra prose.

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 tool has zero parameters and 100% schema coverage, so there is no parameter meaning to add. The description correctly implies this is a direct action with no inputs.

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: 'Stop the shared app-server this bridge talks to.' It distinguishes this tool from the thread/turn siblings by naming the bridge's app-server as the target, making its unique role clear.

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 an explicit trigger: 'Use it when work is handed off and the Codex desktop app is open,' plus the reason ('two app-servers on the same ~/.codex state make the app stutter'). It also reassures about the next startup, so an agent knows when it is safe and expected to call it.

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