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?

Annotations already declare destructiveHint=true, openWorldHint=true, and non-idempotency, so the safety profile is covered. The description adds real context beyond that: a bridge writer lock it must not leave behind, an authorization precondition, Desktop-mode requestId identity rules, and the 40s cap on the overall call even though timeoutSec allows up to 3600. It does not describe auth/credential requirements beyond the user-authorization note.

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 action is front-loaded in the first sentence, followed by usage, mode rules, and the sibling pointer. Dense but slightly long-winded; the requestId rules repeat what the schema already says, which weakens justification for the length.

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 mutating tool with no output schema, the description covers workflow, mode differences, alternative tools, and lock cleanup. It stops short of stating what is returned (the threadId appears only inside a parameter description) and the failure/error behavior of the 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 coverage is 100%, so the baseline is 3, but the description adds cross-parameter semantics the schema states per-parameter: a fresh requestId per independent task kept exactly on retries, omission in legacy mode, and the Desktop 40s cap conflicting with the timeoutSec ceiling. That interaction guidance is genuinely additive.

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 precise multi-step verb sequence — create a named session at a project directory, send the prompt, return Codex's reply, hand off to Desktop without leaving the bridge lock behind. It is clearly distinguishable from siblings start_codex_thread and 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?

It names the triggering condition ('independent new work when the user explicitly or through standing instructions authorizes new conversations') and routes unfinished work to the explicit alternative send_to_codex_thread. Mode-specific guidance (Desktop vs legacy app-server) is also given.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, but the description adds valuable behavioral context: the mode-dependent behavior with turnId and the risk of omitting items without it. This goes beyond the annotation's bare safety profile.

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 fluff; the core purpose is front-loaded, and the caveat about turnId is placed second. Every word 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 read-only tool with simple parameters and existing annotations, the description covers the purpose, mode-specific behavior, and parameter context. It lacks explicit output format but that's not required without an output schema, and the schema covers parameter defaults.

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 parameters are already documented. The description adds extra meaning for turnId, explaining it should be the exact turnId from send_to_codex_thread for authoritative data, which enriches the schema's description.

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?

Clearly states the action 'read' and the resource 'Codex thread', with the qualifier 'without sending anything' that distinguishes it from send_to_codex_thread. The mention of Desktop mode and turnId further differentiates it from siblings like open_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?

Provides explicit guidance on when to pass turnId and why, indicating the context of use (read-only). However, it does not explicitly name alternatives or when-not-to-use, though the sibling list implies them.

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 destructive=true, non-idempotent and open-world, so the mutation/safety profile is partially covered. The description adds real context beyond that: the thread retains full history, cwd and model; Desktop-owned tasks must use Desktop delivery; and a legacy 'active writer' failure has a recovery path via codex_bridge_status. It stops short of describing what a wait/timeout actually returns.

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 applicability rule lead the paragraph, and the negative instruction ('Do not close the task, create a replacement, or ask the user to copy the message manually') is a useful closer. It is dense with operational detail by necessity, but a couple of sentences about legacy relay repair sit awkwardly mid-paragraph.

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, no-output-schema orchestration tool in a multi-agent setup, the description covers selection, persistence semantics, Desktop constraints, and failure recovery. Return handling is only implied (the schema notes a 40s cap that still returns a threadId), and the 'wait' behavior on non-Desktop paths is not spelled out, but the essentials are 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?

Schema description coverage is 100% and all 9 params (including the effort enum range and the 40s Desktop cap) are documented in the schema itself. The description only marginally re-frames cwd/model/name via 'the thread keeps its full history, cwd and model,' so it does not add meaning beyond the structured fields. The baseline 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?

The description states a specific verb and resource: 'Send a prompt as a new user turn inside an existing Codex thread and wait for Codex to answer.' It distinguishes itself from start_codex_thread by insisting on 'inside an existing Codex thread' and from delegate_to_codex by tying it to 'the same unfinished task.' An agent can select it without opening 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?

Explicit when-to-use ('the same unfinished task, including follow-up fixes, clarifications, or results') and when-not-to-use ('independent new work belongs in a new conversation when authorized'), plus a prerequisite ('Use list_codex_threads first if you do not know the threadId'). It also routes Desktop-owned tasks to native delivery, naming the alternative path.

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, openWorldHint=true, idempotentHint=false. The description adds operational details beyond annotations: Desktop mode atomic creation, requestId handling on retries, and that the tool creates a visible task. However, it does not elaborate on why it's destructive or what side effects occur beyond task creation.

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, front-loaded with the core action and condition, then routing guidance. Every sentence earns its place and there is no redundancy.

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 complexity (creates a new thread, multiple parameters, mutation), the description covers usage conditions, alternatives, and key behavioral traits. It lacks details on error handling or what happens on failure, but with full schema coverage and annotations, it is largely 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 coverage is 100%, so the schema already documents all parameters thoroughly. The description mentions 'initial prompt' and 'fresh requestId' behavior, which aligns with schema but adds minimal semantics beyond it (e.g., retry consistency). Baseline 3 is appropriate when schema does the heavy lifting.

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: 'Start a new Codex task' and clearly indicates it creates a new thread. It distinguishes itself from siblings by explicitly naming send_to_codex_thread and delegate_to_codex and describing when to use each alternative.

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 provides explicit guidance: use when the user explicitly or through standing instructions authorizes a new conversation; use send_to_codex_thread to continue unfinished work with an original threadId; use delegate_to_codex to also wait for a reply. This covers when to use this tool vs 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 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.