backdraw

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is covered. The description adds genuine context beyond that: it explains the underlying mechanism (pressing Stop in the background tab and closing it), which tells the agent the in-progress output is abandoned and the tab is torn down.

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, both load-bearing: the first defines the action and its applicable states, the second explains the mechanism. Front-loaded with no padding.

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 one-parameter mutation tool with full annotation coverage and no output schema, this is nearly complete: action, applicable job states, and side effects are all stated. Only the behavior on non-cancellable jobs (error vs. no-op) is left unstated.

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 required parameter and schema coverage is 100%, so the description need not restate job_id. It adds no format, source, or lookup guidance for the id (e.g., from job_status or generate_image), 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?

Specific verb+resource: "Cancel a queued or running ChatGPT image job" tells the agent exactly what is affected and over what states. It does not differentiate itself from siblings like job_status or fetch_images, though the verb makes the distinction largely self-evident.

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 scopes usage to queued or running jobs, which implies when the tool is applicable, but it never states when not to use it (e.g., already-completed or failed jobs) nor references job_status as the way to check state first. Usage is implied rather than guided.

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, it discloses the wait_seconds timing behavior, the STILL RUNNING/QUEUED return state, and the follow-up action with the job_id, which is the information an agent needs to drive this tool. It does not spell out that files are written to disk (readOnlyHint=false despite 'without sending anything'), which would have been helpful given the output_dir parameter.

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 key action and link requirement are front-loaded, followed by usage triggers and return behavior. It is dense but each clause (timeout/retry, earlier chat, wait_seconds, STILL RUNNING) contributes; only the 'Like generate_image' aside slightly compresses two ideas into one sentence.

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 five parameters, no output schema, and openWorldHint=true, the description covers the essential return semantics (timeout states, job_id) and the non-generating nature of the call. The gap is that file-writing side effects and the output_dir interplay are only implicit, which matters for a remote-fetch tool.

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 five parameters thoroughly. The description reinforces wait_seconds' default and explains that aspect_ratio should be re-passed from a generate_image job, but adds little beyond that; 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 ('Download the generated images of the latest answer in an existing ChatGPT conversation (by its link)') and explicitly scopes it to non-generating retrieval ('without sending anything'), which separates it from siblings generate_image and job_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 gives explicit triggers ('when a job timed out or failed... but the chat finished later', 'or to save images from an earlier chat') and routes the agent to job_status when the result is STILL RUNNING/QUEUED, so there is no ambiguity about when to use it or what to do next.

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 annotations: no API key or extra cost, work happens in a background tab so the user's active tab and input are never touched, a bounded wait_seconds, and the complete result taxonomy (SUCCESS with saved paths, NEEDS REFERENCE IMAGE, CHATGPT REPLIED WITHOUT AN IMAGE, STILL RUNNING, QUEUED). It also discloses file placement and centre-cropping behavior, none of which the annotations convey. Nothing contradicts readOnlyHint=false / openWorldHint=true / idempotentHint=false.

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 purpose, then the safety guarantee, then the outcome handling — a sensible order with no filler. It is a dense single block that partly restates schema text (wait_seconds default 45, aspect_ratio cropping rules), which costs it a point on tightness.

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 12-parameter, asynchronous, open-world tool with no output schema, the description supplies exactly what is missing: the return statuses, the job_id continuation path, where files land, and how references interact with collections. An agent can drive the full poll loop without guessing.

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 genuine interpretive guidance: put shape in aspect_ratio rather than the prompt, use reference_images for edits and character consistency, and use reference_collection plus list_collections for saved sets. It stops short of explaining output_dir, send_as_is or auto_reattach, leaving those entirely to the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Names a specific verb pair (generate/edit) plus the resource (an image) and the exact execution channel ('through the user's own logged-in ChatGPT account in Google Chrome'). It clearly separates itself from siblings like job_status, fetch_images and list_collections by describing a chat-driven creation workflow rather than polling, fetching or listing.

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?

Explicitly states 'Use it whenever the user asks for an image, visual, illustration or concept art... in any language', and routes to alternatives: keep calling job_status with the job_id for STILL RUNNING/QUEUED, see list_collections for saved reference sets, and prefer a fresh chat with reference_images over conversation_url for exact edits. This is a full when/when-not/alternative map.

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 annotations: the 45-second default exists to stay under a 60-second client tool timeout, unfinished jobs require repeated polling rather than blocking, and the no-job_id branch returns concrete diagnostics (Chrome/extension connectivity, selected project, images folder, queue, recent jobs). The description is consistent with idempotentHint=true and destructiveHint=false, describing only reads and repeated safe polling.

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 the primary job-checking use, then the wait/poll contract, then the fallback no-argument mode. Dense but every clause carries actionable information, 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?

No output schema exists, yet the description names the exact sentinel results an agent must branch on (STILL RUNNING, QUEUED) and enumerates what the diagnostics mode returns. For a zero-required-parameter polling tool, nothing an agent needs in order to call it correctly 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?

Even though schema coverage is 100%, the description supplies semantics the schema cannot: the origin of job_id, the rationale behind the 45-second default and the client timeout it avoids, and the crucial but non-obvious fact that omitting job_id switches the tool into bridge-diagnostics mode. That last point is a behavioral contract, not a restatement of the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Check a ChatGPT image job by job_id') plus a second distinct mode ('Without job_id it reports the bridge itself'). It names the result states (STILL RUNNING, QUEUED) and the connected sibling tool (generate_image) that produces the job_id, so an agent can distinguish it from cancel_job or fetch_images 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?

Gives clear call conditions: use it with a job_id from generate_image, and re-invoke while the result says STILL RUNNING or QUEUED. It also explains the no-argument diagnostic use case. It stops short of explicitly naming when to prefer cancel_job or fetch_images instead, so it is clear context rather than fully enumerated alternatives.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety and scope are covered; the description adds genuinely new behavior by describing the return shape and ordering ('each with its image count, folder and files (newest first, with the site they came from)'). The only omission is any note on collection count/volume limits, which is minor for a zero-parameter 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?

Two sentences, purpose front-loaded, with the Chrome/right-click parenthetical explaining provenance rather than padding. The nested parentheses ('(right-click an image, "Add to Backdraw")' and '(up to 16 references; reference_files picks specific ones)') are dense but each carries real constraint 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?

There is no output schema, so the description must convey return values itself — and it does, listing per-collection fields, ordering, and the source-site detail. Combined with the annotations covering read-only/closed-world and the schema being empty, an agent has everything needed to call this and use the 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?

Zero input parameters, so the baseline is 4 and there is nothing in the schema to contradict. The description still adds downstream semantics by explaining that a returned collection name becomes generate_image's reference_collection value, tying the output to another tool's parameter.

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?

Specific verb + resource ('List the reference collections the user saved in Chrome') with the origin of that data spelled out (right-click an image, 'Add to Backdraw'), so an agent knows exactly what corpus this covers. It also enumerates the fields returned per collection (image count, folder, files newest first, source site), which separates it cleanly from list_projects and the job 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?

It explicitly routes the agent forward: 'Pass a collection's name as generate_image's reference_collection to attach its images (up to 16 references; reference_files picks specific ones).' That names the sibling tool, the parameter to feed, and the alternative path for a subset of files. It stops short of stating when not to call this (e.g. when the user already named a collection), so it is clear context rather than full when/when-not guidance.

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, so safety is covered. The description adds a genuinely useful behavioral detail — that this reads from a background tab in ChatGPT's sidebar — which explains why latency or tab state may matter. However, it omits what happens if no ChatGPT tab is open or no projects exist, leaving failure behavior undisclosed.

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 covering purpose, mechanism, and output, followed by a short usage cue. No wasted text, though the parenthetical slightly interrupts the main purpose 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-param, read-only, no-output-schema tool, the description is mostly adequate. But with no output schema, the agent would benefit from knowing the return shape (list of project names? IDs?) and what 'selected for images' looks like, plus prerequisites like having ChatGPT open.

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?

Zero parameters, so the baseline is 4. The description correctly implies no input is needed and describes the selection status surfaced as output ('show which one is selected for images').

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 (List) and resource (Projects in the user's ChatGPT account), which distinguishes it clearly from sibling select_project. The parenthetical about reading from ChatGPT's sidebar in a background tab adds useful implementation scope, though it doesn't explicitly name the sibling it contrasts with.

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?

'Use it during setup' gives only a loose temporal cue. It doesn't say when to prefer list_projects over select_project, nor what to do once results are returned. Usage context 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 cover safety signals (readOnlyHint=false, idempotentHint=true, destructiveHint=false, openWorldHint=true). The description adds useful behavioral context: the selection is remembered and affects future image chats, and the name is matched loosely. It does not detail authentication or error behavior, but it adds meaningful state semantics beyond 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?

Two sentences, front-loaded with the primary action and effect, followed by the two input modes. No wasted text.

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 state-setting tool with two optional parameters and no output schema, the description covers the essential action, persistence effect, and input formats. It could do slightly more on error handling or confirmation behavior, but it is otherwise 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 both parameters. The description adds important semantics beyond the schema by noting that the name is 'matched loosely' and that the URL is a project link of the form https://chatgpt.com/g/g-p-…/project.

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 ('Select and remember') and resource ('ChatGPT Project'), plus the scope ('where new image chats are created'). It is clear, though it does not explicitly distinguish itself from sibling tools like 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?

The description implies usage by stating the project is where new image chats are created, and it explains the two input modes (name or URL). However, it gives no explicit guidance on when to use this instead of list_projects or how to recover from a failed match.

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