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

Annotations cover safety (not read-only, openWorld, idempotent, not destructive), and the description meaningfully adds resource-consumption behavior: it spends one of the designer's free monthly boosts or a purchased team boost, and spends nothing when a boost is already active. That is real side-effect transparency beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Four compact sentences, each carrying distinct information (effect, spend source, precondition, edge case). The critical precondition arrives third rather than first, which slightly weakens front-loading but wastes nothing.

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 single-parameter tool with no output schema and annotations that already carry the safety profile, the description covers effect, cost of the action, the consent precondition, and the already-boosted branch. Nothing essential for correct invocation 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 the run_now schema description already states it only starts parked jobs and never spends a boost. The description's 'run_now: true asks for only that' largely restates the schema, so baseline 3 is appropriate.

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

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

The description states a specific effect: a boost doubles today's budget and starts parked runs, spending a free monthly or team boost. That is a clear verb+resource. It does not name a sibling to contrast with, but the sibling list is entirely unrelated design tools, so differentiation is not needed here.

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 strong, explicit precondition: only call after the user explicitly agrees to spend a boost in this conversation. It also explains the already-boosted case. No alternative tool is named, but no plausible alternative exists among the siblings.

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/closed-world, so the safety profile is covered. The description adds genuine value beyond that by disclosing the content of the response — modes with option semantics, website settings with ranges and recommended values, credit rule, required inputs and result kind — which matters because there is 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?

The first sentence is a long run-on list, and 'its settings' is listed twice ('what its settings do to the result' and 'its settings (the website controls with ranges...)'), which reads as redundant rather than clarifying. The trigger sentence is crisp and well placed at the end, but the enumeration could be tightened.

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 describing the return content and does so thoroughly: modes, option meanings, settings with ranges and recommended values, credit rule, required inputs, result kind. It is complete enough to know what an agent will get back, with only minor overlap/redundancy.

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 `tool` parameter with 100% schema description coverage (including the td_... vs bare-id convention), so the schema does the heavy lifting. The description adds no extra meaning about the parameter itself, which is the baseline 3 when coverage is full.

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 enumerates exactly what the tool returns about another tool (best use, comparisons, settings, modes, credit rule, inputs, result kind), so the resource is unambiguous. However, it is written as a noun-phrase list rather than a verb+resource statement, and it never distinguishes itself from siblings like `guide` or `list_tools`, which plausibly overlap.

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 two concrete triggers: call before running a tool whose modes the user has not chosen, and call when the user asks what a mode does. That is actionable context, but there are no when-not conditions and no routing to the sibling `guide`/`list_tools` 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=false, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds useful content-type context (what actually lands on disk), but says nothing about overwrite behavior at the destination or whether a partial/failed download leaves files behind – notable gaps given the idempotentHint.

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, no filler, and the core action is front-loaded before the usage condition. Every clause earns its place by either naming the artifacts or naming the trigger.

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 ideally would say what the call returns (e.g., file paths) and how success/failure surfaces. It covers when to call and what is written, but the return shape and destination-overwrite semantics are left unspecified, which is a meaningful omission for a disk-writing 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 description coverage is 100%, so all four parameters (kind, name, task_id, output_dir) including defaults and the enum are already documented in the schema. The description's mention of 'PSD' and 'bundle' loosely maps to the kind enum but adds no syntax or default behavior beyond it, 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 ('Save a completed job's outputs to disk') and enumerates the artifact types it handles (images, unpacked zips, PSD, Channeling bundle). It also positions itself relative to the job_status sibling, so an agent can tell it apart from the job-creation 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?

Gives explicit triggering conditions: 'Use after job_status reports completed, or to fetch a job's files again.' This names the prerequisite tool and the re-fetch case. It stops short of stating exclusions (e.g., that calling before completion fails), 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, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: answers are grounded in the website's own documentation, and results can legitimately differ from the original. It does not state answer format or any limits, but the bar is lower given the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core purpose, and every parenthetical clause maps a topic value to its meaning, so nothing is wasted. It is one long run-on sentence, which is dense but not padded.

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 only two parameters, 100% schema coverage, and no output schema, the description covers the essential decision surface: what the tool answers and which topic selects which content. It could say more about the shape of the returned guidance, but nothing critical for invocation 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 description coverage is 100%, so the baseline is 3, but the description earns above that by explaining what each topic value actually returns (choose_tool = tool fit, workflows = typical chains, compare = how tools differ, etc.). It also clarifies the optional tool param's role for compare and models.

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 ('Answers how-to questions from the website's own documentation') and enumerates exactly what topics it covers, from tool selection to credits. This clearly separates it from the sibling processing tools, which perform actions rather than answer questions.

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 parenthetical mapping routes the agent to the right topic value for each kind of question (choose_tool for tool fit, workflows for chains, compare for differences, etc.), which is strong usage guidance. It stops short of saying when NOT to use this tool (e.g. vs describe_tool/list_tools) or that tool is only needed for compare/models.

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 usefully adds the state machine (processing/completed/failed/cancelled), the polling/wait behavior, and that result URLs are returned. It doesn't mention auth requirements or failure-detail behavior, keeping it short of 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?

Two tight sentences with zero filler; the core status semantics are front-loaded and the optional wait behavior follows. 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?

With no output schema, the description carries the return-value burden and does so adequately by naming states, progress, and result URLs. Minor gaps remain around failure details and how the result URLs relate to download_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?

Schema coverage is 100%, so both parameters are already documented, including the 0-3600 range and default. The description reinforces wait_seconds as an optional blocking poll but adds no syntax or format detail beyond the schema, 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?

Names a specific verb (status) and resource (a submitted job) and enumerates the possible states plus the return payload (progress and result URLs). An agent can distinguish it from the sibling download_result, though the description never names that sibling 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?

Implies usage after submission ('a submitted job') and explains that wait_seconds optionally blocks until completion, but never states when to prefer this over download_result or what to do once the job is completed. Context 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?

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds genuinely useful non-annotation context: the shape and content of the result (one-line description + credit rule), which matters since there is 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?

Two short sentences, front-loaded with the deliverable and followed immediately by usage and the alternative. 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 no-parameter, read-only enumeration tool, the description covers purpose, return content, usage, and the routing alternative, and annotations cover the safety profile. Nothing an agent needs to invoke 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?

Zero parameters, so the baseline is 4; there is nothing for the description to disambiguate. It correctly implies a no-argument enumeration call.

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 (design tools) plus the exact payload: a one-line description and credit rule for each tool. It also distinguishes itself from the sibling describe_tool by assigning that tool the per-tool detail role.

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 explicit use cases ('what can you do', picking a tool) and names the alternative (describe_tool) with the condition that selects it (need a tool's modes). No inference required.

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 only declare readOnlyHint/idempotent/openWorld, so the description usefully adds that a browser opens automatically and that the server keeps polling in the background. That background-polling and browser-launch behavior is real context not captured in structured fields. It stops short of describing token lifetime or failure/expiry 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?

Three tight sentences, action verb front-loaded, no filler. Each clause carries load: what it does, what it returns, and the two follow-up options.

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 states the return shape (URL and code) and the follow-up paths, and annotations cover the safety profile. It is adequate for a 2-parameter, no-required-params login starter, though it omits failure/expiry handling.

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 already 100%, so the baseline is 3; the description goes slightly beyond by tying the parameters to workflow outcomes ('the browser opens automatically unless open_browser is false', 'set wait_seconds to block until linked'). It adds intent, though not values beyond the schema defaults.

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 ('Start the device-code login') and immediately describes the concrete return ('a URL and a code'), so the agent knows exactly what this tool initiates. It also names the sibling 'whoami' as the confirmation path, distinguishing it from other auth-adjacent 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?

Gives clear contextual routing: browser opens automatically unless open_browser is false, and the agent is told either to call whoami to confirm or to set wait_seconds to block until linked. It does not state explicit when-not conditions (e.g. what to do if already authenticated), so it falls short of a 5.

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

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

Annotations declare readOnlyHint=true and destructiveHint=false, yet the description says the tool ends the session on the server and forgets the stored token – both are state changes that terminate access and erase credentials. That directly contradicts the read-only / non-destructive annotation profile, which is the exact mismatch this dimension is meant to catch.

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: the action ('end the session') comes first and the side effect ('forget the stored token') follows. Nothing is padded or repeated.

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 tool this covers the essentials: what it does and that the token is discarded. It could add one clause about the consequence (subsequent calls require re-authentication), and the annotation conflict noted above leaves the agent's safety model uncertain.

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 the schema cannot be underspecified and the baseline is 4. The description correctly implies no inputs are required and adds nothing misleading about arguments.

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 and resource: end the server-side session and discard the stored token. An agent can immediately tell this is the inverse of the sibling 'login'. It stops short of 5 only because it never names that sibling 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?

Usage is implied rather than stated: an agent infers it should call this when it is finished with the session. There is no explicit when-to-use, when-not-to-use, or reference to 'login' as the counterpart operation, which for a 38-sibling server would be cheap to add.

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 the safety profile (readOnly=false, destructive=false, openWorld=true, idempotent=false). The description adds one genuinely useful non-annotation fact – results are written to disk and paths returned – plus a pattern-quality caveat, but says nothing about credit cost, processing time, or how the source image is treated.

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 purpose, then use case, then a useful output note. Four compact sentences with little waste, though the mode parenthetical slightly duplicates 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 an 11-parameter tool with no output schema, the description covers purpose, best-fit input, mode trade-offs, and the return shape (file paths). The complex interaction flags (review_settings, wait, estimate_only) are well documented in the schema, 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 description coverage is 100%, so the schema fully documents all 11 parameters, including the mode enums and interaction flags. The description only echoes the similar/same modes and the 1-4 output count, adding no syntax or behavioral detail beyond the schema; 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 concrete verb+resource: 'add depth/relief to the design', plus the 2D-flat-to-3D framing and the embossing use case. This clearly separates it from siblings like td_embroidery_effect or td_sketch_to_design, though it never names an alternative 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?

The 'Best for' clause gives a clear context (flat 2D textile design, buyer presentations) and 'Clear, well-defined patterns work best' sets an input-suitability expectation. It also sketches the similar-vs-same choice, but offers no when-not-to-use guidance or named 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=false, openWorldHint=true, destructiveHint=false. The description usefully adds the automatic 20 MB Legacy fallback and that result files are written to disk with paths returned — real behavior beyond annotations. It still omits cost/credit implications, processing time expectations, and failure modes.

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 purpose, then a compact mode note and a use-case list. Well-structured with no filler, though the use-case enumeration is slightly long relative to the rest.

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-param, no-output-schema tool, the description covers what it does, when it applies, the mode/auto-fallback behavior, and that paths are returned. Credit cost and typical runtime are not addressed but the schema handles most operational detail.

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 parameters are fully documented in the schema (including the mode prompt-behavior rule, wait, estimate_only, output_dir non-overwrite). The description adds only the mode/20 MB note, so baseline 3 is correct.

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 ('sharpen a blurred design') with concrete use cases (out-of-focus, motion-blur, soft fabric photos, blurry social references) that distinguish it from siblings like td_super_scaler or td_fabric_texture_removal. An agent can route to this tool immediately.

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 'Best for' list gives clear positive fit signals, but there is no explicit when-NOT-to-use guidance or routing versus sibling de-blur/upscale tools. The mode guidance (Pro recommended, auto-switch to Legacy over 20 MB) is helpful context but not alternative-selection 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=false, destructiveHint=false, openWorldHint=true, and idempotentHint=false, so the safety profile is covered. The description adds genuinely useful context beyond that: results are written to disk and their paths returned, and the Unlimited model is plan-gated. It does not mention upload behavior or credit cost (both only surfaced via schema params).

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 is front-loaded in the first clause, followed by model availability, use cases, and output behavior. It is compact for a ten-parameter tool, though the colon-chained sentences are dense and the model/plan note sits awkwardly between purpose and use cases.

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 correctly states what comes back (file paths on disk) and covers model plan constraints. It omits the upload/credit-charging mechanics, but those are represented by dedicated schema parameters (estimate_only, unlimited_bundle), so an agent has enough to call the tool correctly.

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 ten parameters are already documented in the schema, which sets the baseline at 3. The description restates the model choice and plan gating but adds no syntax or format detail beyond what the schema provides.

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 ('remove the background and replace it with solid white'), which is more precise than the bare name. The 'Best for' clause distinguishes it from removal siblings like td_watermark_removal and td_fabric_texture_removal by use case, though it never names an alternative 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?

The 'Best for' list gives concrete scenarios (isolating motifs, product shots, prepping for layering), which implies when to reach for this tool. However, there is no when-not guidance and no pointer to the sibling removal tools an agent should consider instead, so routing is left to inference.

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

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

Annotations declare the safety profile (not readOnly, not destructive, openWorld), but the description adds meaningful behavior beyond them: outputs are written to disk and their paths returned, and "No settings" signals there is no artistic configuration. It stops short of describing auth or credit-charging details.

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 action, then use cases, then a quality caveat and output behavior, in a compact run of sentences. Every sentence earns its place, though it is a dense colon-chained sentence rather than maximally crisp.

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 usefully explains that results are saved to disk and paths returned, and it covers input suitability. For a 7-parameter tool, the reliance on 100%-covered schema for parameter detail is reasonable, leaving only minor gaps in return-value specifics.

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 the schema already documents all seven parameters in detail. The description adds only the "No settings" summary, which is helpful context but not syntax or format detail beyond the schema. 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 (trace the outline of the design) and names concrete use cases (screen printing, tech packs). It is clear enough to distinguish from most siblings like td_vectorizer or td_embroidery_effect, though it never explicitly contrasts 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?

The "Best for" clause gives clear conditions for use (outline-only version of a filled design, avoiding manual tracing) plus an input constraint (high-contrast, well-defined art). It does not name an alternative tool or when-not-to-use, so it falls short of 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?

Annotations already declare it is not read-only, not idempotent, open-world, and non-destructive, but the description adds value beyond them: it discloses the exact output artifacts, that results are written to disk and their paths returned (important with no output schema), and that the call is credit-priced ('Free for a limited time; priced by the server'). It stops short of describing failure modes, overwrite behavior, or rate/credit-consumption specifics.

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 purpose is front-loaded and the sentences are short and largely non-redundant. The pricing sentence is the weakest link but still earns its place for a credit-consuming call, and the description stays compact despite the tool's complexity.

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 correctly carries the return-value burden by naming the PSD bundle, preview PNG, and returned file paths, and it flags the paid-call aspect. Given the 100% schema coverage of 14 parameters and existing annotations, the remaining omission (async/task_id flow, credit-estimate behavior) is minor and largely covered by the schema.

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 every one of the 14 parameters is already documented in the input schema, and the description adds essentially no parameter-level meaning (no mention of trap_mode, n_clusters, review_settings, or wait). The baseline of 3 applies when the schema does the heavy lifting.

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

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

The description gives a specific verb and resource: 'separate the design into print screens (spot channels)', and it names the concrete artifacts produced (multichannel PSD, preview PNG). It is clear about the operation, but it never contrasts itself with plausible siblings such as td_colour_layering, td_colourways, or td_foil_separation, so the agent gets no explicit differentiation.

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?

'Best for: preparing a design for screen or rotary printing' supplies a usage context, so the intended situation is implied rather than absent. However, there are no when-not conditions and no named alternatives among the many separation/layering siblings, leaving routing decisions to inference.

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

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

Annotations declare readOnlyHint=false, openWorldHint=true and idempotentHint=false, so the write/network profile is already known. The description adds useful context beyond that — 'Result files are saved to disk and their paths returned' — but says nothing about credit consumption, upload behavior or async wait semantics that the schema handles only implicitly.

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 core action and the chaining contract in the first two clauses, with the 'Best for' line last. The 'Best for: reading a design's motif and background colours (hex, Pantone TCX...' sentence is visibly truncated mid-thought, which costs a point on structure.

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 correctly carries the return-value burden: JSON palette with hex/Pantone/percentage plus saved result-file paths. That is enough to call the tool and consume its output; only cost/credit expectations for a billed write operation are 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?

Schema description coverage is 100%, so all seven parameters (wait, image, output_dir, estimate_only, review_settings, timeout_seconds, unlimited_bundle) are already documented in the schema. The description adds only the extract_task_id naming convention for chaining, which is usage rather than parameter meaning; baseline 3 is appropriate.

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

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

Specific verb+resource: 'extract the design's palette as JSON (motif and background colours with hex, pantone and percentage)'. It also positions itself as 'step 0' in a named pipeline, which distinguishes it cleanly from the suggest, match-reference, swatch-grid and replace siblings.

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 downstream routing: 'Pass its task_id as extract_task_id to the suggest, match-reference and swatch-grid tools; use the hexes with td_color_matching_replace.' It states both the condition and the alternative consumers, leaving nothing to inference.

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 the mutation/open-world/non-idempotent profile, so the bar is lower. The description adds real behavioural context beyond that: results are written to disk with paths returned, and the return includes mapping sets intended for td_color_matching_replace. It doesn't cover credit cost or failure/partial behaviour for multi-reference runs.

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 its palette source are front-loaded, and the closing sentence about saved files is worth keeping. The first sentence is dense and slightly run-on, but 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?

For a ten-parameter, no-output-schema tool, the description covers what the tool does, what it consumes (palette/reference images), and what it produces (JSON plus mapping sets, files on disk). The mechanical async parameters (wait, timeout_seconds) are left entirely to the schema, which is acceptable but leaves a small gap.

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

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

Schema description coverage is 100%, so all ten parameters are already documented. The description reinforces the palette-source choice (extract_task_id or colors) but adds no format, default, or constraint detail beyond what the schema provides; 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: it recolours plans to match each reference image, sourcing colours from the design's extracted palette via extract_task_id or colors. It also names the downstream sibling (td_color_matching_replace), so an agent can place it in the color-matching pipeline without opening other schemas.

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?

"Best for: matching the design's colours to the colour style of one or more reference images" gives clear when-to-use context and the extract_task_id reference signals the intended upstream step. It stops short of naming when-not to use it or explicitly contrasting with siblings like td_color_transfer or td_style_transfer.

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=false, openWorldHint=true, idempotentHint=false and destructiveHint=false, so the safety profile is covered. The description adds value beyond that by disclosing the output behavior – 'Result files are saved to disk and their paths returned' – and by implying credit consumption via estimate_only, though it does not discuss failure modes or overwrite semantics (that detail lives in the 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 tight sentences, front-loaded with the pipeline position and the key input relationship, with no filler. Slightly terse on the remaining ten parameters, but nothing is redundant or padded.

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, non-idempotent, open-world job tool with no output schema, the description covers the essentials: what it produces, where files land, and how it chains from the grid step. The safety/execution annotations plus the schema's per-parameter detail fill the remaining slots, so nothing critical 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 description coverage is 100%, so the baseline is 3. The description still adds meaning: it clarifies that 'image = the ORIGINAL design used for the grid' (not the grid image), establishes grid_task_id as the preferred alternative to grid_image_url, and ties bg_only back to the grid run's value. That is genuine value beyond the per-parameter text.

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 – regenerate full-size images for chosen swatch-grid cells – and positions itself precisely as 'Color Matching Auto step 2' relative to the grid step. It names the sibling tool (td_color_matching_swatch_grid) as the source of grid_task_id, so an agent can place it in the pipeline without opening either 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?

The 'Best for: getting clean, full-size versions of the swatch-grid variants you liked' line gives clear when-to-use context and anchors it after the grid run. It does not, however, state any when-not-to-use conditions or what to do if the grid was never run, so it stops short of full routing 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 declare mutation (readOnlyHint=false), open-world, and non-idempotent behavior, so the safety profile is partly covered. The description adds real value beyond that: outputs are written to disk and their paths are returned, and sets are capped at 15 with one output per set — critical behavior given there is 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?

Four compact sentences, front-loaded with the action and the parameter distinction before the pointer to the sibling and the output note. Every sentence carries information; nothing is 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 10-parameter mutation tool with no output schema, the description covers the key gaps: output location/returned paths, the mappings vs sets choice, and how to get input hexes. Remaining minor gaps (permissions, failure/overwrite behavior) are largely addressed by the schema's 'Files are never overwritten' note.

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 goes further by disambiguating the two near-identical array parameters (mappings = single output, sets = multiple outputs, max 15) — a distinction the schema alone makes easy to confuse.

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 ('swap specific colours in the design') and clarifies the two mapping shapes: 'mappings = one set' vs 'sets = several alternative sets, one output each'. It names the sibling td_color_matching_extract_colors for sourcing hexes, though it doesn't differentiate from other color-matching siblings like suggest or match_reference.

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?

'Best for: swapping specific design colours for exact new values' gives explicit selection context, and the pointer to td_color_matching_extract_colors tells the agent how to obtain inputs. It lacks explicit when-not-to-use guidance versus the other td_color_matching_* tools.

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 it is not read-only, not idempotent, and open-world. The description adds useful side-effect context beyond annotations: it returns JSON plus mapping sets, saves result files to disk, and returns their paths. It does not mention credit use or waiting behavior, but those are partially covered by schema parameters.

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 tool identity and core action, and its four sentences are mostly efficient. There is slight redundancy: 'for a market and palette type' appears in the first sentence and again in the 'Best for' sentence, but the structure remains clear and navigable.

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 explain the return shape (JSON plus mapping sets, saved file paths), which is essential. The remaining 12-parameter complexity is handled by the schema's 100% description coverage, so the description is sufficient for a caller, though it could briefly note credit estimation or the async/wait 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 the schema already documents all 12 parameters in detail. The description only reinforces that the palette comes from extract_task_id or colors and mentions market and palette type, adding little beyond the schema's own descriptions. Baseline 3 is appropriate.

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

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

The description states a specific verb and resource: five palette suggestions for a market and palette type, sourced from an extracted palette. It distinguishes itself from upstream extraction (extract_task_id or colors) and downstream replacement (td_color_matching_replace), and 'trend-aware palette ideas for a target market and palette type' differentiates it from reference-matching and swatch-grid siblings.

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 clear context with 'Best for: getting trend-aware palette ideas for a target market and palette type' and identifies which inputs to source from. However, it does not explicitly state when not to use it or name alternative tools like td_color_matching_regenerate or td_color_matching_match_reference, so it stops short of the 5-level alternative routing.

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=false, openWorldHint=true and idempotentHint=false, so the mutation profile is covered. The description adds real context beyond them: the outputs are written to disk and their paths returned, and the tool is the first half of a two-call workflow whose task_id feeds the regenerate step. It omits credit/charging behavior, which is notable for a tool that offers estimate_only.

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 action and its output, then the follow-up call, then the 'Best for' scoping, then the return behavior. Every sentence carries information; slight density of domain jargon ('Auto mode', 'Print Ready') costs it the top score.

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 correctly covers the return behavior (files saved to disk, paths returned) and the task_id handoff. For a 12-parameter, credit-consuming, non-idempotent generation tool it could still say more about cost and about how the numbered grid maps to variant numbers used by regenerate.

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% (baseline 3), and the description still adds meaning: it maps num_options to the count of variants in the grid, clarifies that the palette comes from either extract_task_id or colors, and frames wait/task_id as part of a two-step flow. It does not explain bg_only, print_ready or review_settings semantics, which remain schema-only.

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 ('one numbered grid image with num_options colour variants') plus the palette source, and explicitly positions itself as 'Auto step 1' with td_color_matching_regenerate as the follow-up. An agent can distinguish it from td_color_matching_suggest, td_color_matching_match_reference and td_color_matching_replace 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?

Gives a clear usage context ('Best for: quickly previewing several colour variants side by side (Auto mode)') and an explicit next step with the parameters to carry forward. It does not state when to prefer this over the sibling suggest/match_reference/replace tools, so it stops short of full alternative routing.

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 openWorldHint, non-read-only, non-idempotent and non-destructive. The description usefully adds the output behavior — files written to disk with paths returned — but says nothing about credential/plan requirements, credit consumption, or the wait/task_id async model that a mutation tool arguably should surface.

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 compact sentences with the core action and the payoff (disk paths) front-loaded. The 'Best for:' sentence partly restates the opening line's mechanism before adding the new examples, which is mild redundancy but not waste.

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

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

For a tool with no output schema, the description covers the destination and form of the result (files on disk, paths returned), which is the key return-value fact. Async/task_id handling, credit estimation and review_settings prompting are all covered by the schema, so the remaining gaps are small.

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 the schema already documents all eight parameters in detail, including defaults and constraints. The description adds no parameter-level meaning beyond that baseline, which is the expected 3 when the schema carries the full load.

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 transform ('recolour the source design with the palette of a second image') and adds that structure/composition are preserved, which implicitly separates it from td_style_transfer. It stops short of naming sibling tools such as td_style_transfer or td_color_matching_match_reference, so differentiation is inferred 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?

The 'Best for:' clause gives a clear use case with concrete examples (seasonal trend colours, buyer brand colours) on an existing design. There is no statement of when NOT to use it or which alternative to pick for a related goal (e.g. style transfer vs palette transfer), so usage is contextual but not routing.

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=false, destructive=false and openWorld=true, so the safety profile is covered. The description adds genuine context beyond them by disclosing the output contract: a .psd file written to disk with returned paths. It stops short of mentioning credit consumption or the async/wait behaviour, but the core behavioural traits are present.

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 is front-loaded and the four clauses are compact with no filler. Slightly dense in the middle clause where mode and layer-count options are crammed together, 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 10-parameter tool with modes, async submission and credit charging, the description covers what it does, the key mode choice, and the return artefact (no output schema exists, so this matters). It omits credit/estimate behaviour and interactive settings flow, though the schema covers those.

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 the schema already documents every parameter including mode, n_clusters, is_automatic, wait and estimate_only. The description only echoes the mode and layer-count ranges at a high level, adding little syntax or default detail beyond what the schema states. 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 — 'separate the design into colour layers in a PSD' — and adds a use-case qualifier ('turning flat-colour art into one editable layer per colour') that distinguishes it from neighbours like td_object_layering and td_foil_separation. An agent can identify the operation and its output artefact 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?

'Best for: turning flat-colour art...' gives clear when-to-use context, and the mode note (simple recommended vs advanced) signals a preference. However, no sibling alternative is named and there is no explicit when-not guidance, so the agent must infer the boundary against the other layering/separation tools.

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 the safety profile (write, open-world, non-idempotent, non-destructive). The description adds genuinely useful behavior not in the annotations: results are written to disk and file paths are returned, and grid=true also produces a buyer sheet. It omits the async/job and credit-cost aspects, but the incremental disclosure over annotations is real.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with the core action, then eligibility, then output behavior. Every sentence earns its place, though the 'Best for' sentence packs several scenarios and runs a little long.

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 15-parameter generative tool with no output schema, the description usefully closes the return-value gap by stating files are saved to disk and paths returned. It leaves async/job and cost behavior to the schema, but the coverage is otherwise solid for an agent to call it correctly.

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 the schema already documents all 15 parameters in detail (enums, ranges, defaults). The description only restates a few of these (counts, locked colours, grid buyer sheet), adding no syntax or format meaning beyond the schema, 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?

States a specific verb and resource ('generate colourway options for the design') plus the concrete option counts (6/12/24/48) and the locked-colour behavior. This is clear and non-tautological, but it does not explicitly differentiate itself from the many sibling colour tools (e.g. td_color_matching_regenerate) that an agent might confuse it 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?

The 'Best for' sentence gives concrete usage scenarios: a buyer wanting the same print in other colours, or a range needing pastel/deep/dark stories from one bestseller. That is strong when-to-use guidance, though it offers no explicit when-not or named 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=false, openWorldHint=true and non-idempotent, so the safety profile is covered. The description adds real value beyond that: results are written to disk and their paths returned, which tells the agent this is a side-effecting, file-producing operation. It does not mention credit consumption or rate limits, but with annotations present this is adequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with the core action, then the variant list, then usage and output behavior. The variant enumeration partially duplicates the schema, but the structure is efficient and nothing is buried.

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 20 parameters, no output schema and a write operation, the description covers the essentials by naming the return shape (saved file paths) and the variant modes. Missing only cost/credit awareness and disambiguation from td_design_generation, both of which an agent would want before invoking.

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 20 parameters are already documented — including the per-variant output counts that the description repeats ('prime 1-5, new 1-5, old 1-4'). The description adds nearly nothing beyond what the schema states, 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 — 'generate design variations from the source image' — and enumerates the variant modes. However, it never distinguishes itself from the near-identically named sibling td_design_generation, so an agent cannot tell from the text alone which of the two generation tools to pick.

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?

'Best for: generating fresh design variations from a reference image without writing prompts' plus concrete scenarios (filling collection gaps, style-consistent range, quick concept exploration) gives clear when-to-use context. There is no when-not-to-use guidance or explicit pointer to td_design_generation / td_sketch_to_design, which is the missing half.

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

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

Annotations declare non-destructive, non-idempotent, open-world mutation, so the safety profile is covered. The description adds genuinely new behavior: 'Result files are saved to disk and their paths returned,' which tells the agent it must handle file paths rather than inline data. It omits credit/charging behavior and the interactive settings-confirmation flow, keeping it below 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?

Three tight sentences with the core action front-loaded, followed by usage context and the side-effect disclosure. No filler or redundancy.

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

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

For a 13-parameter mutation tool with no output schema, the description covers what the tool does, when to use it, and what it returns (file paths), with the schema supplying all parameter detail. It reasonably withholds return-value internals since no output schema exists, but says nothing about cost/credit implications or failure modes.

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 13 parameters are already documented in the schema, including gaps, dpi, output_dir and review_settings. The description only restates the gap range and the 'not all four 0' rule already present in the schema, adding no semantics beyond it. 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 ('extend the design outward by a gap on each side') with the 0-10 range and the 'not all four 0' constraint, then adds a 'Best for' clause that distinguishes it from siblings like td_repeat_set or td_border_outline. An agent can identify the operation 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?

The 'Best for' sentence gives concrete usage context (growing a small swatch or centre motif outward while preserving style, palette and texture), with two worked examples. It does not explicitly name an alternative tool or a when-not-to-use condition, so it falls short of 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?

Annotations declare the safety profile (readOnlyHint=false, openWorldHint=true, idempotentHint=false), so the description's added job is behavioral context, and it delivers: results are written to disk with paths returned, and the Mood Board capability is absent. It stops short of stating that long jobs submit asynchronously and return a task_id (that detail lives only in the wait/timeout schema text), so it is not fully self-contained.

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 front-loaded sentences: mode enumeration, scope exclusion, recommended use case, and output behavior. Efficient overall, though the 'Best for' sentence partially restates the text_to_image mode already described in the first 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?

For a 14-parameter, enum-heavy tool with 100% schema coverage and no output schema, the description covers the essentials an agent cannot get from structured fields: which mode corresponds to which intent, the recommended default, the Mood Board exclusion, and where results land. Nothing critical 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 description coverage is 100% and the schema already documents mode semantics, required fields, enums, file constraints, and the review/wait/estimate flow in detail. The description adds little parameter-level meaning beyond echoing the mode names, 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 specific verbs and resources across all three operating modes (generate/re-imagine/repaint a design), naming the mode enum values inline so an agent can map user intent to mode without opening the schema. It also scopes the tool by noting the website's Mood Board is not available here, which prevents a plausible wrong selection.

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 clear per-mode when-to-use guidance and an explicit 'Best for' default (image plus written prompt), which is exactly the routing information an agent needs. What's missing is differentiation from close siblings such as td_design_creation, td_sketch_to_design, or td_design_extension, so the agent must still infer which of those to pick.

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 cover the safety profile (readOnlyHint=false, destructiveHint=false, openWorld=true), and the description adds genuine operational context beyond them: results are saved to disk with paths returned, files are never overwritten, estimate_only charges nothing, and the Unlimited bundle is server-decided. It doesn't discuss rate limits or failure behavior, so not 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?

The purpose and mode list are front-loaded in the first two sentences, and the result-file behavior closes it out. It is dense but every clause carries information; no padding 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 correctly states what comes back (files on disk with returned paths) and covers mode, count and estimate behavior. Minor gaps remain around failure/timeout behavior for long jobs, but nothing essential to a correct call 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 description coverage is 100%, so the schema already documents all ten parameters in detail. The description echoes the mode names and output count but adds only marginal semantics (e.g. 'one output per mode') on top of what the schema states. Baseline 3 is appropriate.

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

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

States a specific verb and resource: 'extract the print from a garment photo as a flat design.' It also enumerates the modes and the 1-4 output count, so an agent can tell it apart from siblings like td_sketch_to_design or td_embroidery_effect 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?

The 'Best for' clause gives clear context (garment photo, mockup or outfit; worn, mannequin or flat-lay), and the schema's mode field instructs the agent never to choose a mode for the user and to call describe_tool. No explicit when-not or named sibling alternative is given, which keeps it below a 5.

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

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

With annotations present (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true) the safety profile is already covered, so the description's job is additive. It contributes two genuinely useful facts not in structured data: the fixed '13 credits' cost and the fact that 'result files are saved to disk and their paths returned.' It stays silent on async/job timing, but wait/timeout_seconds in the schema cover that.

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 action ('render the design as embroidery') before the option list, then closes with cost and output location. The 11-item stitch enumeration is somewhat list-heavy and duplicates the schema enum, marginally reducing density but not obscuring the core intent.

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, so the description usefully states that files are written to disk and paths are returned, closing the biggest return-value gap. Credit cost and the sampling-oriented use case are also covered, though job lifecycle and failure behavior remain unspecified.

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

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

Schema description coverage is 100% and every enum option carries a human-readable label plus an explicit 'omit it and the tool returns the modes' instruction, so the schema already does all parameter work. The description's stitch-type list merely restates the enum. Baseline 3 is appropriate.

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

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

States a specific verb and resource: 'render the design as embroidery,' and enumerates the exact stitch styles available, so an agent knows precisely what transform this performs. It does not, however, name or contrast itself with the many adjacent effect siblings (td_3d_effect, td_channeling, td_style_transfer), leaving that routing to inference.

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?

'Best for: previewing a design as realistic embroidery or Indian craftwork (e.g. Zardozi, Chikankari, Phulkari) before sampling' gives a clear use context including the pre-sampling workflow. No when-not conditions or named alternatives are provided, and given the large sibling set of effect tools that is a real gap.

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 cover the safety profile (readOnlyHint=false, destructiveHint=false, openWorld). The description adds behavioral value beyond that: it states 1-4 outputs are produced and that result files are written to disk with paths returned, so an agent knows outputs are persisted rather than inlined. It stops short of cost/auth/overwrite details.

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 core action, then the best-for context, then the output behavior. All sentences earn their place, though the best-for clause and the 1-4 outputs detail make it slightly run-on rather than maximally tight.

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 describing returns and does so ('files saved to disk, paths returned') and notes output count. For an 8-param tool with full schema coverage and annotations, this is nearly complete, missing only cost/overwrite specifics that live in the schema.

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 eight parameters are fully documented in the schema itself (including output_dir non-overwrite, wait, num_outputs limits). The description adds no parameter-level syntax or semantics 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?

States a specific verb (flatten/remove) and resource (fabric weave/texture from a photographed design), with a concrete example (digitising an old swatch). This is clearly distinguishable from siblings like td_anti_blur or td_background_removal, which target different artifacts.

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 'Best for:' clause gives a clear context for use (flat scan/photo of printed fabric -> clean digital design) with an example. It does not, however, name when NOT to use it or point to alternative tools for adjacent tasks.

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 the safety profile (write op, non-destructive, non-idempotent, open-world), so the bar is lower. The description adds real value beyond them by disclosing that result files are written to disk and their paths returned, and that a vector EPS is optional.

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 core action, then modes, then best-for, then output behavior. It is compact, though the leading 'Foil Separation:' label and the mode list partially restate the title and 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 complex 17-parameter tool with no output schema, the description covers purpose, modes, intended input, and the fact that file paths are returned. Interactive behaviors like review_settings and credit estimation are handled in the schema, so the description is adequate without being exhaustive.

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 the schema already documents all 17 parameters in detail, including mode semantics and the interactive review_settings behavior. The description only restates the mode names and the vector EPS option, adding no syntax or meaning beyond the schema, 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 ('build the foil layer for the design') and enumerates the four operating modes, so an agent knows exactly what the tool produces. It does not, however, explicitly differentiate itself from sibling effects like td_embroidery_effect or td_vectorizer, leaving the distinction to be inferred from the resource name.

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 'Best for' clause gives clear usage context and even input constraints ('a flat, high-contrast print design'), which is genuinely useful for selecting this tool. It stops short of naming alternatives or stating when not to use it, so it does not reach the 5 level.

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 only cover the generic safety profile (readOnlyHint=false, openWorldHint=true, destructiveHint=false), so the description usefully adds that the result is a .psd written to disk with paths returned, and that input quality affects results. It does not disclose credit consumption or processing time, though the schema's estimate_only/timeout_seconds partially cover those 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?

Front-loaded with the core action and output format, then use cases and constraints. Four short sentences, though 'Result is a .psd file' and 'Result files are saved to disk and their paths returned' overlap slightly.

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 7 parameters, no output schema and only generic annotations, the description supplies the key missing context: output artifact type, on-disk persistence, and input suitability. An agent could call it correctly, though it doesn't mention runtime/cost behavior that the schema only hints at.

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 every parameter is documented in-schema, so the baseline is 3. The description's 'distinct motifs on a contrasting background' adds mild guidance about the image parameter, but nothing about wait, output_dir or review_settings behaviors.

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: 'split the design into a layered PSD, one layer per object,' and names the output format. The 'by object or motif' phrasing implicitly separates it from the sibling td_colour_layering, but no sibling is named explicitly, so it falls 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?

Gives a clear use case ('Best for: splitting a design into editable layers by object or motif, e.g. to move flowers apart in Photoshop instead of redrawing') plus an input precondition ('works best with distinct motifs on a contrasting background'). No explicit when-not-to-use or named alternative (e.g. colour layering) is offered.

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

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

Annotations declare the mutation/open-world profile (readOnlyHint=false, idempotentHint=false), and the description adds genuinely new behavioral facts: results are written to disk and their paths returned. It does not mention credit consumption or job latency, but the output-side effect disclosure is real value beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the core purpose before the 'Best for' detail, with no filler. It is slightly redundant, repeating 'make a design print-ready' and the 1-4x enlargement twice, which costs it the top score.

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 13-parameter tool with no output schema, the description covers the essential framing (what it produces, that files land on disk, where paths go) while the schema carries per-parameter detail. Missing only the cost/latency and job-vs-sync expectations that a heavy processing tool would ideally surface.

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 13 parameters (including nuanced ones like creativity, resemblance, output_format and review_settings) are already documented in the schema. The description only restates the 1-4x range and DPI behavior, adding nothing the schema lacks; 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+resource+mechanism: make a design print-ready by enlarging 1-4x with AI-filled detail and a target DPI baked into the file. That is concrete and distinguishable in substance, but it never names or contrasts with the very similar sibling td_super_scaler, so an agent must infer the boundary itself.

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 'Best for:' clause gives a clear usage context (finished designs, low-res buyer/archive/small-format files, 1-4x enlargement). It offers no when-not-to-use guidance and names no alternative tool, so the routing decision against td_super_scaler or td_anti_blur is left 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 declare readOnly=false, destructive=false, idempotent=false and openWorld=true, so the safety profile is covered structurally. The description adds that result files are saved to disk and their paths returned, which is real behavioral value given there is no output schema, but it omits long-running/async behavior (wait, timeout_seconds) and the credit/billing implications implied by estimate_only and unlimited_bundle.

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 purpose is front-loaded, but the third sentence redundantly re-lists the same five modes already enumerated in sentence two ('block, half brick, half drop, mirror or step'), and 'turn the design into a seamless repeat' is echoed in the 'Best for' clause. The repetition costs it a point.

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 15-parameter tool with no output schema, the description covers the essential missing piece, namely that outputs are written to disk and returned as paths. The remaining parameters (dpi, brushes, review_settings, timeout) are fully explained in the schema, so the description is largely complete, though it says nothing about the billing/credits dimension implied by estimate_only.

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

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

Schema description coverage is 100% and each parameter carries its own rich description (including the 'never choose for the user' guidance on mode parameters), so the schema does the heavy lifting. The description only restates the repeat-type enum, which is already fully documented, adding no syntax or format detail beyond the schema.

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

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

The description names a specific verb+resource ('turn the design into a seamless repeat') and enumerates the concrete repeat modes (block, half_brick, half_drop, mirror, step). No sibling tool performs a repeat/tiling operation, so an agent can cleanly distinguish this from tools like td_vectorizer or td_fabric_texture_removal.

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?

'Best for: turning a design into a seamless repeating tile for fabric, wallpaper or rotary printing' gives clear when-to-use context and the target domains. It does not name an alternative tool or state when NOT to use this one, so it stops short of the 5-level routing 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 the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true, idempotentHint=false), lowering the bar. The description adds genuine behavioral context beyond them: 'Result files are saved to disk and their paths returned,' which compensates for the missing output schema. It still omits credit cost and processing-time behavior, so not 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?

The definition is front-loaded with the core purpose before the 'Best for' clause and the input-quality caveat, and every sentence earns its place. It is appropriately sized for a 10-parameter tool, though the trailing quality note is slightly less essential than the rest.

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 10-parameter mutation tool with no output schema, the description covers purpose, ideal inputs, and the file-save/return behavior that the missing output schema would otherwise leave ambiguous. It does not mention credit estimation or the review_settings flow, but those are documented in the schema, so nothing critical 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 description coverage is 100%, so the schema already documents all 10 parameters, including the rich style enum guidance ('never choose for the user', 'Call describe_tool'). The description only echoes 'optionally in a named style' and adds no syntax or format detail beyond the schema, 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: 'colour a line sketch into a finished design, optionally in a named style.' The 'Best for' clause names the input domain (sketch, line art, wireframe), which effectively separates it from the many sibling design tools such as td_style_transfer and td_design_generation that operate on arbitrary images.

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?

'Best for: turning a sketch, line art or wireframe into a full-colour, detailed design' gives clear when-to-use context, and 'Clear, simple sketches with well-defined lines work best' adds a quality precondition. However, it names no alternative tool and states no exclusions, so an agent is not explicitly routed away from siblings.

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=false, openWorldHint=true and idempotentHint=false, so the write/open-world nature is covered. The description adds output behavior the annotations don't convey: result files are saved to disk and their paths returned, plus the reference-mode mimicry semantics. It stops short of covering cost/auth beyond what the schema (estimate_only) implies.

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 verb+resource, then modes, then 'best for', then output. Four sentences with no filler. Slightly dense with the mode and output details, but each 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 9-parameter, enum-bearing tool with no output schema, the description covers the two modes and the disk-output return format, which is the main thing an agent needs that isn't in structured data. Marginal gaps (pricing/auth beyond estimate_only) are minor given the rich schema.

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 the baseline is 3, but the description adds genuinely non-schema semantics: the mutual exclusivity of garment_type and reference_image and the fact that reference mode overrides garment_type. That elevates it above the schema-only 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?

States a specific verb and resource: 'build a tech-pack style spec board from a garment photo'. It also delineates the two operating modes (garment_type vs reference_image), which is the key distinction an agent must grasp to call it correctly. The purpose is unmistakable.

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 'Best for' clause and the mode-selection sentence ('Give garment_type, or use Reference mode') give clear context for when to use each path. It does not, however, name any sibling tool as an alternative for a garment photo that isn't a spec board, so routing among the many td_* tools is left to inference.

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

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

With annotations already declaring readOnlyHint=false, destructiveHint=false and non-idempotency, the description adds real value by disclosing the output behavior: result files are saved to disk and their paths returned. It also confirms the layout-preserving semantics, though it says nothing about credit costs or the review/estimate flow.

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 tight sentences front-loaded with purpose, then usage context, then output—no filler. Minor redundancy in restating the tool name, but nothing wasteful.

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 complex 11-parameter, no-output-schema tool, the description covers the two operating modes, the intended use case, and the return format (file paths on disk), which is the key missing piece without an output schema. Credit/bundle/estimate mechanics are left to the schema but are not essential to correct invocation.

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

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

Schema description coverage is 100%, so the schema already documents all 11 parameters in detail; the description adds essentially no parameter-level meaning beyond reusing the mode/style example names already in the schema. Baseline 3 is appropriate when the schema carries the 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 states a specific verb (restyle) and resource (the design) and explicitly names its two modes (library style vs. image_to_image). It is clear about what it does, though it never distinguishes itself from the nearby sibling td_color_transfer, which an agent could easily confuse it 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?

The 'Best for' clause gives clear usage context: applying an artistic surface look while keeping the design layout intact, including example styles. It lacks explicit when-not-to-use guidance or named alternatives (e.g. color transfer), so it stops just short of full routing 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 the safety profile (not read-only, not idempotent, open world), so the bar is lower. The description adds genuinely useful behavior not covered anywhere else in structured fields: results are written to disk and their paths are returned. It still omits the async/task_id flow (wait=false), credit spend, and job-failure behavior, so it is not fully transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with the capability, then the ideal use case, then the output artifact. Every sentence earns its place and nothing is 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?

Wait – this is an 11-parameter tool. Reconsidering: for a tool of this complexity the description covers what it does, when to use it, and where results go, and the 100%-covered schema carries all parameter semantics. The only missing piece is the task_id/async lifecycle. Lowering to 4.

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 the parameter descriptions are unusually rich (enums explained, recommended values marked, 'never choose for the user' guidance). The description only restates the 2x/4x/8x range and detail enhancement, which the schema already documents, so per the baseline rule a 3 is correct.

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+resource+scope: 'AI enlargement 2x/4x/8x with detail enhancement.' An agent can tell this is an upscaler versus a denoiser/anti-blur tool from the 'rebuilding lost detail and enlarging' framing, but no sibling is named explicitly, so the differentiation is implicit 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?

The 'Best for' clause gives a concrete triggering condition (low-resolution, blurred, compressed, or old 72 dpi archive JPEGs and small web images destined for large-format printing). It stops short of stating when NOT to use it or naming the overlapping alternative (td_anti_blur) for blur-only cases.

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 the non-read-only, open-world, non-idempotent profile, so the description's job is to add context — and it does, disclosing that files are written to disk and their paths returned rather than returned inline. It does not mention credit charging, plan gating for unlimited_bundle, or job timeout behaviour.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, purpose and format mapping front-loaded before the 'Best for' rationale and the return-behaviour note. No filler or restated name/title.

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 14-parameter conversion tool with no output schema, the description still covers the goal, the use case, the output-format families and where results land. Annotations carry the safety profile, and the schema covers every parameter in depth.

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 14 parameters are already fully documented in the schema, including the ready_for/format groupings the description repeats. The description adds no syntax or constraint detail beyond what the schema provides, which is the baseline-3 case.

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 ('convert the design to vector') and names the exact output families (png/tiff/eps for Photoshop, svg/pdf/eps for Illustrator). No sibling tool in the list competes with this capability, and the scope is unambiguous.

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

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

The 'Best for' sentence gives a concrete trigger: turning flat-colour raster art like a JPEG logo or print into editable, scalable vector. It does not name an alternative tool or state when NOT to use it, so it falls short of the explicit routing that a 5 requires.

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 the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true, idempotentHint=false), so the bar is lower. The description usefully adds that results are written to disk and paths returned, and flags the rights-to-modify constraint, but does not expand on credit consumption or the point at which the model must be specified by the user.

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 purpose and target artifacts are front-loaded, and the text is compact with no filler. The "Best for" list is slightly dense but every clause carries usable scoping 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 nine-parameter tool with full schema coverage and no output schema, the description supplies the missing return-value context (files saved to disk, paths returned) and the rights caveat. It is adequate and largely complete; only the omission of credit/processing implications keeps it from the top.

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

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

Schema description coverage is 100% and all nine parameters are thoroughly documented in the schema, including the model-selection rule and output_dir behavior. The description only echoes the "Standard or AI Pro model" distinction and adds no format, default, or syntax detail beyond the schema, 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 names a specific verb and resource ("remove watermarks from a design") and scopes the target artifacts precisely (watermarks, logos, stamped branding, overlaid text). It does not, however, explicitly differentiate itself from closely related siblings such as td_background_removal or td_fabric_texture_removal, leaving that separation to inference.

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?

"Best for: cleaning watermarks... e.g. a residual mark on a licensed stock file or old branding on archive designs" gives clear, concrete usage context. It stops short of stating when NOT to use it or naming an alternative tool, so it is strong but not exhaustive.

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, destructiveHint=false and openWorldHint, so the safety profile is covered; the description adds the non-obvious trait that it surfaces a pending login in progress. That is genuine context beyond the annotations, though it says nothing about behaviour when unauthenticated or failing.

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 the returned fields and followed by the pending-login caveat. 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?

With no output schema, the description must convey the return shape, which it does by listing the key fields plus the pending-login state. It omits error/unauthenticated outcomes, a minor gap for a trivial no-arg introspection 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?

Zero parameters, so the baseline is 4 under the rubric. The description returns nothing extra needed here, as there is nothing to parametrise.

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 the resource (the connected account) and enumerates what is returned: email, organisation, credits, plan access, enabled tools. An agent can distinguish it from session-mutating siblings like login/logout, though it never states the verb as directly as a sibling routing line would.

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 the tool to call to inspect the current session, but no when-to-use/when-not or alternative (e.g. vs. login, or vs. list_tools) is stated. The pending-login clause hints at a pre-auth check use case but stops short of guiding it.

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