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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description earns credit by disclosing the concrete contents of the report (platform, resolved codex binary, app-server endpoint and liveness, deep-link support, macOS integrations), which is meaningful for a tool with no output 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?

One front-loaded sentence that enumerates the reported fields without filler. The list is dense but each item adds information rather than restating the name.

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?

With no output schema, the description appropriately describes what the report contains, and annotations cover safety. The remaining gap is guidance on when in a workflow to run it and how to interpret a 'not live' result.

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?

There is a single optional parameter with 100% schema description coverage, so the schema carries the semantics. The description never mentions 'cwd' or explains what checking an intended target directory yields, so 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?

States a specific verb ('Report') and a specific resource (how the bridge is wired on this machine), then enumerates the facets checked. It is clearly a diagnostic/status tool, distinguishable in kind from the action-oriented siblings like open_codex_thread or stop_codex_app_server, though no sibling is named.

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 only implied: a status/diagnostic tool that an agent would naturally call as a preflight before delegating. There is no explicit statement of when to call it versus inspect_bridge_project or prepare_bridge_project, nor any exclusion or prerequisite.

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/non-idempotent/open-world, and the description adds genuinely new behavioral facts: the bridge writer lock is released, Desktop creation yields a durable deliveryId, timeout means continue rather than resend, and the 40s Desktop cap lets the task keep running. This is exactly the beyond-annotation context the dimension rewards.

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?

Front-loaded with the full operation sequence, then the mode-specific rules, then the sibling pointer. Dense but each clause carries operational information; a few phrases (e.g. the lock-release detail) sit awkwardly mid-sentence, slightly impeding scanability.

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?

With 9 parameters, no output schema, and a mode split (Desktop vs legacy app-server), the description covers what comes back (Codex's reply, deliveryId, threadId) and how to proceed on timeout. Nothing an agent needs before calling it 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 coverage is 100%, so the baseline is 3, but the description adds real semantics for requestId (fresh UUID per independent task, retained on retries, omitted in legacy app-server mode) and for timeout/resend behavior that the schema property text alone frames more narrowly. It stops short of explaining cwd/name/model choices, so not a 5.

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 concrete verb chain (create session, send prompt, return reply, hand off to Desktop) on a specific resource, and explicitly contrasts itself with send_to_codex_thread for 'unfinished work'. An agent can distinguish this from start_codex_thread or send_to_worker without opening any 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?

It states when to use it ('independent new work when the user explicitly or through standing instructions authorizes new conversations') and names two alternatives with their triggering conditions: wait_codex_reply on Desktop timeout, and send_to_codex_thread for unfinished work. Exclusions are explicit rather than implied.

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?

Adds substantial context beyond the readOnly/idempotent annotations: it warns that authorization mode is reported separately from shared project-policy state and that a missing policy is only a prerequisite when nextActions says so, which prevents a common misreading of results. It also clarifies that configured files are distinguished from untested live connections. What it omits is any indication of the response shape or how nextActions is structured.

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 non-mutation guarantee and the core purpose are front-loaded, and every sentence carries distinct information with no filler. The telegraphic fragments ('Card extension authorization is a separate check.') are efficient but slightly staccato, making the paragraph read as a checklist rather than a coherent framing.

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?

With no output schema, the description carries the burden of explaining what comes back, and it does so at a useful level: authorization mode, project-policy state, configured-versus-live distinction, and nextActions. The result is sufficient to interpret a response correctly, though the exact fields of nextActions remain undefined.

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 both cwd and taskCards are already documented, including the worktree resolution rule and the no-silent-edit guarantee. The description only indirectly touches taskCards via 'Card extension authorization is a separate check' and adds no new meaning for cwd, 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?

Opens with a specific verb and resource set: 'Read workspace trust and this bridge process's effective messaging authorization without changing files.' That is clearly distinct from mutation-oriented siblings such as prepare_bridge_project and from thread/worker messaging tools, though it never names those siblings directly.

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 meaningful scoping guidance: card extension authorization is a separate check, same-project and new-task checks are not performed here, and it 'does not send messages or create conversations.' This effectively excludes the wrong use cases, but it stops short of pointing at which sibling to call instead for those excluded checks.

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, idempotentHint=true, and openWorldHint=true, and the description is consistent with them. It adds the useful state precondition (the turn must still be running) but does not disclose what happens to the interrupted turn's partial output, whether the thread remains usable, or what errors surface if the turn already completed.

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 sentence with zero filler, and the key qualifier ('still running') is front-loaded. It is arguably under-sized for a destructive operation, but there is no wasted text to trim.

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?

This is a destructive, open-world mutation with no output schema, and the description leaves the important consequences unexplained: what happens to in-flight output, whether the thread state is preserved, and what the caller receives on success or on an already-finished turn. An agent has to guess at the aftermath of the interrupt.

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 threadId and turnId are already documented, including the pointer that turnId comes from send_to_codex_thread. The description adds no further meaning about either parameter, so 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 ('Stop') and resource ('a turn that is still running in a Codex thread'), which is more precise than the title. It implicitly distinguishes itself from stop_codex_app_server by scoping to a single turn, but never names that sibling to make the distinction explicit.

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 'still running' precondition implies when the tool applies, but there is no explicit guidance on when to interrupt versus letting a turn finish, nor any pointer to stop_codex_app_server for the server-level alternative. Usage is inferable 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 establish that this is a read-only, open-world operation. The description adds useful context by naming returned fields (id, title, cwd, last update, status), but it does not discuss ordering, pagination defaults, or whether archived threads are included.

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 tightly written sentence that front-loads the operation and immediately explains its purpose. Nothing is redundant or misplaced.

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 full schema coverage and annotations covering safety, the description is nearly complete. It names the returned fields and the selection purpose, though it could mention ordering or default recency behavior.

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 all four parameters are already documented in the schema. The description does not add parameter-level meaning beyond what the schema provides, 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?

The description states a specific verb and resource ('List recent Codex threads') and clarifies the output fields, so the agent can distinguish it from thread-reading or messaging tools. It implies the downstream action ('pick the exact threadId to talk to') but does not name the sibling tool explicitly.

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 implied usage: call this to find a threadId before talking to a thread. It does not explicitly state when not to use it, nor does it name alternative tools such as open_codex_thread or read_codex_thread.

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, idempotentHint, and non-destructive, so safety is covered. The description adds context the annotations do not: the listing includes both CLI workers and background task receipts, and worker identities are distinct from chat IDs — a real behavioral caveat for downstream calls.

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 what is listed and followed by the disambiguation caveat. Every clause carries information; there is 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?

With no parameters, no output schema, and read-only annotations, the description covers what the tool returns at a functional level and how its identifiers differ from chat IDs. It could mention roughly what fields a worker entry has, but nothing needed to invoke it correctly is absent.

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 takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. No parameter-level detail is missing.

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 and two concrete resources: CLI workers and this caller's background task receipts. It also draws a boundary against Desktop chats, which separates it from the codex/chat-oriented siblings, though it never names an actual sibling tool.

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: you call this to discover workers before addressing one, and the description warns never to use a native chat ID as a worker destination. That is a useful constraint, but there is no explicit routing such as 'use worker_status to check a single worker's state'.

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 idempotent=true and destructive=false; the description adds genuinely new context by disclosing the mechanism (a codex://threads/<id> deep link) and the OS-level side effect of foregrounding a desktop app on Windows/macOS. It stops short of the operationally useful failure modes — behavior when the app is not installed, the OS is unsupported, or the thread id is unknown — so a 4 rather than a 5.

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 sentence, front-loaded with the action and platform support, with the rationale appended. Nothing is padded or repeated from the schema.

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 two-parameter launch tool with no output schema, the description covers mechanism, platforms, and intent. The remaining gap is outcome disclosure — whether anything is returned or how failure surfaces when the app cannot be opened — which an agent would want in order to handle errors.

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 both threadId and background are already documented in the schema; the description only echoes the thread id inside the URL template. It adds no meaning about the 'background' flag or about acceptable threadId formats, so 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?

States a specific verb and resource ('Bring a Codex thread to the front') plus the platform scope (Windows or macOS), which an agent cannot infer from the name alone. It implicitly contrasts with transcript-reading tools via 'instead of reading the transcript afterwards', but never names a sibling such as read_codex_thread, so differentiation is suggestive rather than explicit.

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 a clear usage condition: use this when a human should watch the work live rather than read the transcript afterwards. It does not state exclusions or failure conditions (e.g., what to do on Linux, or if the desktop app is not installed), nor does it name the alternative tool to call instead.

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 (destructiveHint=true, idempotentHint=true), the description discloses that backups and verification are performed, that existing grants are reused, and that revocations are only cleared with explicit reauthorization while parent revocations persist. The warning 'configured is not connected' is a behavioral caveat an agent could not derive from the annotations or schema, and nothing in the text contradicts the declared destructive/idempotent 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?

The usage precondition is front-loaded and every clause carries safety or scope information; the exclusion list is efficient despite its length. It is dense and somewhat repetitive around verification ('verify live communication separately; configured is not connected' overlapping with the nextActions instruction), but nothing is padded for its own sake.

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 destructive, non-read-only mutation with no output schema, the description supplies the prerequisites, the side-effect boundary, the recovery story (backups), and what the agent should do after return (follow nextActions, verify connectivity). It does not describe what the response contains beyond nextActions, which is a minor gap given annotations already signal the mutation profile.

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 cwd, taskCards, and reauthorize are already documented, including worktree resolution and revocation inheritance. The description only re-touches taskCards obliquely via 'check the existing card extension if requested' and adds nothing new about cwd or reauthorize semantics. Baseline 3 is appropriate where the schema carries the parameter 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 write action (persisting Claude workspace trust and a shared messaging grant) scoped to a user-selected project, which is more concrete than the title 'Connect a project to GPT and Claude'. It also enumerates what the tool is not (permission modes, tool approval, messaging, sessions, client restarts), which helps distinguish it from siblings like delegate_to_codex or send_to_codex_thread. It never names a sibling tool explicitly, so differentiation is inferential rather than direct.

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 positive precondition ('Use only when the user explicitly selects a project for onboarding') and explicit prohibitions ('Never invoke to work around a denied message or peer instruction to broaden access'). It also states the conditional follow-up path (Follow nextActions to check the card extension if requested) and tells the agent to verify live communication separately rather than treating configuration as connectivity.

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. The description adds meaningful behavioral context beyond that: passing turnId yields authoritative assistant item IDs, text, and a reply hash, while omitting it may cause the native recent-history view to omit items. It stops short of covering error cases or pagination behavior, keeping it at a 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, front-loaded with the core action and a mode-specific caveat. Every clause carries actionable information, with no repetition 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?

There is no output schema, but the input schema's responsePreferences description covers the response envelope and cursor pagination. The description focuses on the key behavioral caveat around turnId; it could say more about response filtering or default return shape, but it is sufficient 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 coverage is 100%, so the baseline is 3. The description still adds real value for turnId by naming its source (send_to_codex_thread) and explaining its effect (authoritative items vs. possible omissions), which goes beyond the schema's one-line parameter 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?

The description uses a specific verb and resource ('Read a Codex thread') and immediately scopes it with 'without sending anything,' distinguishing it from send_to_codex_thread. It does not explicitly differentiate from open_codex_thread or list_codex_threads, so sibling separation is only partially addressed.

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 a conditional usage rule for turnId in Desktop mode and warns that omitting turnId can produce incomplete history. However, it does not state when to use this tool versus open_codex_thread, wait_codex_reply, or list_codex_threads, so guidance is implied rather than explicit.

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 readOnly, idempotent, non-destructive, so the safety profile is covered. The description adds real behavioral context: queued is not completed, failed/unknown receipts carry a report block for direct display, and unknown work is never auto-replayed. It stops short of describing timeout behavior for waitSec or the set of terminal states.

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?

Four short sentences, front-loaded with the core action and scoping constraint. Each sentence carries information; only the 'show directly in this chat' phrasing is slightly incidental.

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 read-only poll tool with no output schema, the description covers what comes back at a high level (receipt, report block on failure) and the non-replay guarantee. Output shape details are not needed given the annotations and schema coverage.

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 100% schema description coverage, both parameters are already documented, including waitSec's semantics. The description aligns with the schema by noting requestId originates from send_to_worker, but adds no format or edge-case detail beyond it.

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 (read/wait) on a specific resource (durable background task receipt) keyed by requestId. It distinguishes itself from send_to_worker by referencing 'its original requestId' and by clarifying that a queued receipt is not a completed response, though it does not explicitly name siblings like worker_status.

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?

Makes the polling/waiting context clear and warns against treating a queued receipt as a final answer. It does not explicitly state when to prefer worker_status or list_workers, leaving the sibling routing implicit.

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 flag destructive=true, openWorld=true, idempotent=false, and the description adds real behavioral context beyond them: a durable deliveryId is prepared before dispatch, ambiguous acknowledgements are marked unconfirmed rather than accepted, and Desktop calls are capped at 40s while the task continues. The no-resend and no-manual-copy rules are exactly the failure-mode guidance an agent needs.

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?

Purpose and the core usage constraint are front-loaded in the first two sentences, and no sentence is filler. The trailing runbook of edge cases (unconfirmed acks, legacy writer, don't close the task) is dense and slightly sprawling, but each clause maps to a real failure mode rather than restating the schema.

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, non-idempotent, destructive, long-running call with no output schema, the description covers the risky parts: sync vs. async behavior, the 40s Desktop cap, return of a threadId, and what to do on timeout or ambiguity. Nothing an agent must know to invoke it safely 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 coverage is 100% and each parameter carries a detailed description, so the schema does the heavy lifting and baseline 3 applies. The description only marginally supplements it, notably that the thread retains cwd and model, which hints that model/cwd are per-turn overrides rather than durable state changes.

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 and resource (send a prompt as a new user turn inside an existing Codex thread) plus the blocking behavior (wait for the answer). It also draws the line against the obvious sibling by saying independent new work belongs in a new conversation, which separates it from start_codex_thread and delegate_to_codex.

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 (same unfinished task, follow-up fixes, clarifications, results) and when-not (independent new work in a new conversation). It also routes to concrete siblings for the prerequisite and recovery paths: list_codex_threads when the threadId is unknown, wait_codex_reply on timeout, codex_bridge_status when a legacy writer blocks delivery.

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 flag idempotentHint=true and openWorldHint=true, and the description reinforces idempotency with concrete retry semantics (generate requestId once, reuse on retry, inspect rather than resend). It also adds context annotations cannot express — the work continues independently when Desktop apps close or freeze. The gap is destructiveHint=true: nothing explains what side effects are possible or what authorization guarantees make them safe, so the strongest annotation hint goes unelaborated.

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?

Four sentences, front-loaded with the positive action before the exclusions and the retry rule, with no filler. Mild cost: 'explicitly' appears three times and the authorization caveat is restated in both description and schema, making it slightly denser than needed.

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 destructive, open-world, idempotent queued job with no output schema, the description covers preconditions, retry discipline and the recovery tool. The one omission is what a successful call yields — a delivery identifier an agent then passes to read_worker_delivery — which is only inferable from the recovery instruction rather than stated.

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 baseline is 3. The description still adds meaning beyond the schema for requestId — generate once, persist across retries, and resolve ambiguity via read_worker_delivery rather than a new ID — which is a usage contract the pattern/format definition cannot convey. The 'explicitly authorized project' framing similarly adds an authorization bar to cwd that the schema only calls 'absolute path'.

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 and resource — queue authorized work to a separate background CLI worker in a selected project — and immediately draws the boundary against the Desktop-chat siblings ("does not address, open or resume any Desktop chat"). Between that exclusion and the pointer to worker-relay tools, an agent can distinguish this from delegate_to_codex, send_to_codex_thread and start_codex_thread without opening a 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?

It gives explicit when-not guidance (no Desktop chat substitution), an explicit recovery path for a specific failure mode (uncertain result → read_worker_delivery, never resend under another ID), and routes follow-on delegation to the worker-relay tools. The preconditions — explicitly authorized project and explicitly selected cwd — are stated up front.

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 description adds real operational context beyond the annotations: Desktop-mode task creation is atomic, prompt is required when CODEX_BRIDGE_DESKTOP_TASKS=1, and requestId must be reused on retries. However, annotations declare destructiveHint=true and openWorldHint=true, and the description never explains what side effects or persistence justify the destructive flag, so the safety profile stays opaque.

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?

Usage condition is front-loaded, then the Desktop-mode mechanics, then sibling routing — a sensible order. Sentences are dense but each carries distinct information; the requestId clause is slightly repetitive with the schema.

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 five-parameter creation tool with full schema coverage and no output schema, the description covers authorization, mode requirements, retry identity, and sibling routing. Remaining gaps are the unexplained destructive/edit side effects and the absence of any mention of what the call returns (e.g., the new threadId needed for follow-up).

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 all five parameters are already documented in the schema, including the requestId retry/dedup rules and the prompt formatting contract. The description restates the requestId retry discipline and prompt requirement without adding format or mode details the schema lacks, so it sits at 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?

The description gives a specific verb+resource ('Start a new Codex task') and scopes it to 'a new conversation for independent work', which separates it from send_to_codex_thread (continue unfinished work) and delegate_to_codex (also waits for the reply). It never addresses the closely related sibling open_codex_thread, leaving an obvious ambiguity unresolved.

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 authorization condition for use ('explicitly or through standing instructions') and names two alternatives with the condition that selects each. It gives no negative guidance and does not explain when open_codex_thread would be preferred over 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?

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.

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

Annotations already flag readOnly/idempotent, and the description adds real behavioral context beyond them: an unconfirmed acknowledgement does not prove delivery even after MCP reconnect, retries must reuse the same deliveryId, and only the original verified Claude session and accounts can use the receipt. Those auth and idempotency semantics are not derivable from the annotations or 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?

Four dense sentences, front-loaded with the core action and the most failure-prone guidance (retry with the same deliveryId). The opening clause 'Continue a Desktop creation or send using its deliveryId' is slightly awkward, but no sentence is 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?

There is no output schema, and the description compensates by naming terminal outcomes (stops for approval, user input, verification error) and the retry loop. It does not describe the response envelope shape, though the nested responsePreferences schema covers cursor delivery, so the remaining gap is minor.

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 earns extra credit by explaining the receipt lifecycle: the deliveryId persists across timeout retries and is the handle the agent must reuse rather than re-send. It adds no detail on responsePreferences, but the schema already documents that envelope and cursor flow.

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 on a specific resource: continue waiting on a Desktop creation/send identified by deliveryId, and it explicitly says it 'Never sends a message or creates a task,' which separates it from send_to_codex_thread and delegate_to_codex. It never names those siblings directly, so the differentiation is implied rather than stated.

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 when-to-use rules ('On timeout, call again with the same deliveryId'), explicit when-not-to ('do not ask the user to fetch the answer or resend'), and explicit stop conditions (approval, user input, verification error). This is the strongest dimension of the definition.

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 establish that this is a safe, read-only, idempotent status inspection. The description adds substantial non-obvious behavioral context: transport readiness is separate from CLI authentication/model readiness, authentication-unverified can still accept work, and actual job failures should be reported from receipts.

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 front-loaded with the core purpose and each subsequent sentence adds relevant interpretive guidance. It is slightly dense, but there is no obvious filler or repetition.

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?

With no output schema, the description does more than most by explaining key status semantics and avoiding a common misreading of authentication-unverified. It still does not describe the overall response shape or clarify its relationship to sibling status tools, which keeps it from being 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 tool has zero parameters, so there are no parameter semantics for the description to clarify. A baseline score of 4 is appropriate because the schema is empty and complete for this status-inspection operation.

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 gives a specific verb/resource set: inspecting the independent background relay, CLI readiness, and recent diagnostic reports. It is clear what the tool does, but it does not explicitly differentiate itself from sibling status/list tools such as list_workers or codex_bridge_status.

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 useful usage context for interpreting statuses, including that desktop apps may be closed/frozen and that authentication-unverified with canAcceptWork=true is informational rather than a failure. However, it does not say when to use this tool instead of alternatives like list_workers or codex_bridge_status.

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