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

With no annotations, the description carries the full burden, and it does disclose real behavior: a new chat is created in `project`, the call blocks while waiting, and files are written into dest_dir, with file paths returned. However it says nothing about failure/timeout behavior, whether existing files in dest_dir are overwritten, or that the default 900s timeout makes this a long-running call.

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 dense sentences: the workflow is front-loaded and the return-value/next-step note is appended, with 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?

There is no output schema, and the description usefully states the return value (copied file paths), so the basics are covered. Still missing are timeout/failure semantics and documentation for the prompt/timeout_s parameters, leaving an agent guessing on a long-running, file-writing operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate, and it only partially does: `project` is tied to 'new chat in project' and dest_dir to 'copy the result(s) into dest_dir'. The `prompt` argument is left implicit and `timeout_s` is never mentioned at all despite its 900s default materially affecting behavior.

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 (generate an image, copy the resulting file(s) to dest_dir) and even explains the mechanism (delegating to a new Codex chat's image_gen tool). This clearly distinguishes it from chat-oriented siblings like send_message, read_chat, and codex_goal.

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 implies when the tool is used (you want an image produced) and hints at next steps ('open them with your image viewer/Read tool'), but it never states exclusions or names an alternative (e.g. why use this instead of send_message to a Codex chat). Usage is implied rather than spelled out.

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

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

With no annotations, the description carries the full burden and does disclose real behavior: 'edit' replaces the objective and presses Save, and changes are validated against Codex's goal store. However it omits side effects of pause/resume, permission or auth requirements, and what 'get' 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?

Front-loads purpose in the first clause, then packs action semantics into a compact parenthetical list. Dense but every clause carries information; no filler sentences.

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 4-parameter tool with no annotations and no output schema, the description covers the action behaviors well but leaves `project` unexplained and gives no sense of what read/get returns. Adequate but with clear 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 0% and there are 4 parameters, so the description must compensate. It does well for `action` (spelling out get/pause/resume/edit semantics), `chat` (id or exact title), and `objective` (used by edit), but says nothing about the `project` parameter, leaving one of four undocumented.

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 pair and resource ('Read or steer the goal of a Codex chat'), which clearly separates it from siblings like read_chat or list_chats. It doesn't explicitly contrast with any named alternative, so it stops short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description enumerates the actions and what each does, which implies usage, but never states when to choose this tool over read_chat/send_message or what prerequisites (e.g., a valid chat id) are needed. Usage is left to inference from the action list.

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

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

No annotations are provided, so the description carries the full behavioral burden. It adds some useful status semantics (goal status for codex chats, busy/idle/closed for claude chats), but omits pagination/limit behavior, required 'app'/'project' prerequisites, and permission or error behavior.

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 followed by a useful status note. No filler language, though the status sentence is somewhat cryptic without examples.

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?

An output schema exists, so return values need not be explained. Still, with 3 params at 0% schema description coverage and no annotations, the description is incomplete regarding parameter meanings and listing behavior (limit, app selection).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and the description does not explain the 'app', 'project', or 'limit' parameters. The only hint is that 'project' is a name or path from list_projects; 'app' and 'limit' are entirely undocumented, and limit doesn't even appear in the 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?

States a specific verb+resource ('List chats in a project') and adds the ordering ('newest first'). However, it does not differentiate from the listed sibling 'list_projects' (though that sibling lists a different resource) beyond noting that the project argument is a name/path from list_projects.

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 mentions that the project argument can come from list_projects, which implies a chaining context, but provides no explicit when-to-use/when-not-to-use or alternatives for retrieving chats (e.g., read_chat).

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

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the default ordering (most recently active first), but says nothing about pagination, result limits, or authentication requirements for a read-style listing tool.

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 tight sentence with no filler; the resource, the allowed app values, and the sort order all earn their place and are front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter listing tool with an output schema present (so return values need no explanation), the description covers the essentials: what is listed, for which apps, and in what order. Only the lack of sibling routing and pagination/auth context 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?

Schema coverage is 0% and the schema declares 'app' as a plain string with no enum, so the description supplies the critical missing information: the three accepted values ('codex', 'claude_code', 'claude_cli'). This materially compensates for the schema gap, though no default or format notes are given.

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 projects (folders)'), enumerates the valid app values, and specifies the ordering ('most recently active first'). This is clear and actionable, though it does not explicitly distinguish itself from siblings like list_chats.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to choose this tool versus the sibling listing tools such as list_chats, nor any stated prerequisites or exclusions. Usage is only implied by the resource name.

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

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

With no annotations, the description carries the full burden, and it does disclose the shape of the result (what was asked plus each turn's final answer). However, it says nothing about read-only safety, permissions, pagination, or what happens when the chat is not found, leaving meaningful behavioral gaps.

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 filler, and the parenthetical qualification of the chat identifier is placed immediately after the object it describes. Every clause carries information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a four-parameter, unannotated tool with no output schema, the description covers the retrieval concept but omits the semantics of three parameters and any limits on how many messages are returned. Adequate to call the tool in the simplest case, but incomplete overall.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% across four parameters. The description clarifies only one of them (chat accepts an id or exact title), which is useful, but app, last, and project are left entirely undefined with no format, meaning, or default explanation.

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 ("Read the last messages of a chat") and scopes the result to questions and per-turn final answers, which clearly separates it from siblings like send_message or list_chats. It does not explicitly name an alternative, 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 verb and scope imply the use case (fetching recent conversation content), but there is no explicit when-to-use or when-not-to-use guidance, and no mention of how it relates to siblings such as list_chats or wait_reply. 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?

With no annotations, the description carries the full burden and does so well: it discloses desktop-app driving, split-window reuse behavior, that the view returns to the user's prior chats, that claude_cli runs headless with permission_mode, and the notify_caller typing behavior. It omits permission/auth implications of permission_mode and any rate or concurrency limits.

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 and each sentence adds operational detail rather than filler. The chat/project paragraph is dense and could be tightened, but nothing is redundant.

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 6-param tool with no annotations and no output schema, the description covers the return value (job_id), where the answer lands, and the follow-up call. The only real gap is the implicit enumeration of app values and permission_mode semantics.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate, and it explains chat, project, notify_caller behavior, and mentions permission_mode in the claude_cli context. It never cleanly enumerates the valid `app` values even though codex/claude_code/claude_cli are effectively them, leaving that mapping implicit.

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 concrete verb+resource ('Send `text` into a chat and press Enter') and names the distinct app drivers, so an agent can distinguish it from siblings like wait_reply or read_chat without inspecting 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?

It provides explicit conditional guidance: leave chat empty to start a new chat in a project, or use no folder when project is empty, and it names the alternative path ('Otherwise call wait_reply(job_id)'). It stops short of stating when-not to use this tool or prerequisites, so it is not a full 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?

With no annotations, the description carries the full burden, and it does disclose the key trait: this is a blocking wait that ends when the chat answers or timeout_s passes, and it returns the job with its reply. It omits critical behavior such as what happens on timeout (error, empty reply, or partial job) and whether polling/rate limits apply.

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 dense sentence that front-loads the action, the termination condition, and the return value with no filler. Every clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter blocking tool with no annotations and no output schema, the description covers the core contract (wait, terminate on reply or timeout, return job+reply) but leaves the timeout outcome and time unit unspecified. Adequate but with clear gaps an agent would want filled.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% for two parameters, so the description must compensate. It clarifies that job_id identifies the chat being waited on and that timeout_s is the wait bound, but it never states the unit (seconds is only inferable from the name) or the behavior at expiry.

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 (wait), the resource it waits on (the chat behind job_id), and the return payload (the job with its reply). It is distinguishable from siblings like read_chat or send_message, though it never explicitly contrasts itself with them.

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: an agent can infer this is called after an async job was started to await its reply, and the timeout_s mention hints at bounded blocking. There is no explicit when-to-use statement, no when-not-to-use, and no named alternative among the siblings.

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