YuzuGrow

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

With no annotations, the description carries the full disclosure burden. It usefully discloses a credit cost and the AI-vision nature of the operation, but says nothing about whether anything is persisted, whether the call is safe/idempotent, or any rate or length limits on the frames.

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 action and outcome, with the cost caveat appended. No wasted words.

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

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

There is no output schema, but the description indicates what comes back (extracted hook text plus a generated video prompt) and flags the credit cost, which is the key operational fact for an agent. Missing only usage routing against siblings.

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 three parameters (firstFrameUrl, existingPrompt, additionalFrameUrls) are already documented in the schema, including the 'up to 3 more' cap. The description adds no parameter-level detail beyond that baseline.

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

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

The description names a specific verb and resource ('Analyze hook frame(s) using AI vision') and states the outcome: extract hook text and generate a video prompt. It is clear, but it never distinguishes itself from adjacent siblings like remix_hook or enhance_prompt, so an agent cannot route between them from the description alone.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as remix_hook or enhance_prompt. The only contextual note is 'Costs 1 credit,' which is a constraint rather than usage 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?

No annotations are provided, so the description carries the full burden. The verb 'Check' clearly implies a non-mutating read operation, which is useful signal. However, it says nothing about authentication requirements, rate limits, or what a zero/absent subscription state looks like.

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. Both returned pieces of information are named efficiently, and nothing could be cut without losing meaning.

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, read-only query with no output schema, the description covers both data points an agent would call this for. The only mild gap is that no output format is described, though the covered fields make the return shape sufficiently predictable.

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, and the schema is empty with 100% coverage, so there is nothing for the description to compensate for. Baseline 4 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 ('Check') with two concrete resources ('credit balance and subscription status'), so an agent knows exactly what it returns. It does not differentiate from siblings, but the sibling list is entirely media-generation tools with no overlapping purpose, so differentiation is unnecessary.

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?

No when-to-use guidance, prerequisites, or alternatives are given. The usage is self-evident for a balance check, but the description offers no explicit context or trigger conditions.

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

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

No annotations are provided, so the description carries the burden. It discloses a critical non-obvious behavioral trait, the 5-credit cost, and the sequencing dependency on face_swap. It doesn't state whether the operation is destructive to the original image or how long processing takes, but the cost and dependency disclosures are meaningful beyond what any structured field offers.

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 purpose, followed by the conditional usage rule and cost. Every clause earns its place with no redundancy.

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

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

For a single-parameter mutation tool with no annotations or output schema, the description covers purpose, sequencing, and cost. It could mention whether the source image is preserved or what happens to the credits on failure, but the essential calling information is present.

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

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

Only one parameter, and schema description coverage is 100% ('URL of the image to clean'). The description adds no parameter detail but none is needed; a single fully-documented parameter gives a baseline of 4.

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: 'Remove text overlays and watermarks from an image.' It also explicitly distinguishes itself from the sibling face_swap by noting the ordering relationship, so an agent can tell when this tool is the right one.

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

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

Explicit when-to-use: 'Only use AFTER face_swap if the result still has visible text.' It also names the alternative and explains that face_swap already attempts text removal by default, which prevents redundant calls. This is the rare case of explicit 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?

No annotations are provided, so the description carries the full behavioral burden. It describes the output contents structurally but omits whether this operation consumes credits, requires an existing product, persists a plan server-side, or how long it takes. For a generation tool in a suite that includes check_credits, these omissions are significant.

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

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

One sentence with no filler, and the most important information (output type, time horizon, and contents) is front-loaded. Every phrase 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 and no annotations, the description is the only source of shape information, and it partially covers this by naming the plan's components. It is missing behavioral context such as credit cost, persistence, and required auth, which matters for a generation tool. Adequate but with clear gaps.

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

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

Schema coverage is 100% and there is a single optional parameter (productId), whose default behavior is already documented in the schema. The description adds no additional meaning about the parameter, so the baseline 3 applies.

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

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

The description gives a specific verb ('Generate') and resource ('a 3-week content plan') plus the concrete deliverables: daily posting schedule, hooks, and platform rotation. An agent can distinguish this from siblings like analyze_hook, remix_hook, or suggest_captions based on the scope of the output. It stops short of explicitly contrasting with those siblings, so a 4 rather than 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?

There is no when-to-use guidance, no indication of prerequisites, and no mention of alternatives such as suggest_captions or scrape_video for adjacent content tasks. The only usage hint is self-evident from the verb. The presence of a sibling check_credits tool suggests cost considerations that the description never addresses.

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

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

With no annotations at all, the description carries the full burden, yet it only says 'create' and nothing more. It doesn't disclose whether duplicates are allowed, what permissions are needed, whether the operation is reversible, or what is returned. For a mutation tool with zero annotation coverage this is a significant gap.

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 short phrase with no wasted words, and the action is front-loaded. It is arguably under-specified rather than padded, but the size itself is efficient.

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 creation tool with no annotations, no output schema, and no behavioral notes, the description is too thin. The schema covers the three parameters, but nothing tells the agent about required fields in context, side effects, or error 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 url, name, and description are already documented in the schema. The description adds no format, constraint, or default information beyond that, so the 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 ('Create a new product/brand'), so the agent knows it creates a product entity. However, it gives no differentiation from siblings like update_product or list_products, and the 'product/brand' phrasing is slightly ambiguous about what entity is actually created.

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?

No guidance on when to use this versus update_product, or when an existing product should be reused instead of created. The only implied usage is the verb itself; no prerequisites or exclusions are stated.

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

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses that the call creates an Asset record, but it omits important behavioral details such as URL expiration, single-use constraints, required HTTP method, and authorization requirements.

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 two tight sentences with no waste. The primary action and its side effect are front-loaded and easy to scan.

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

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

The description gives the core purpose and side effect, but with no output schema and no annotations, it should say more about the returned URL and upload requirements. It remains minimally adequate because the input schema is fully documented.

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 six parameters are already documented in the input schema. The description does not add parameter syntax, format, or usage details 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?

The description states a specific action: obtaining a pre-signed upload URL, with concrete examples and a disclosed side effect (creates an Asset record). An agent can distinguish this from sibling generation tools 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 description does not say when to use this tool versus alternatives, nor does it mention prerequisites such as authentication or required upload steps. Usage context is implied only by the phrase 'upload a file.'

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

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

With no annotations, the description carries the full disclosure burden. It usefully reveals that improvement is performed by Claude and that each call consumes 1 credit — real behavioral facts beyond the schema — but says nothing about latency, whether the call is safely repeatable, or how the enhanced prompt is returned.

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 no filler, front-loading the action and following with the cost. Every clause carries information an agent can act on.

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

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

For a simple two-required-parameter tool with no output schema and no nested objects, the description covers the action, the LLM backing it, and the credit cost. It is nearly complete; only the return behavior of the enhanced prompt is left implicit.

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 both parameters are documented in the schema, including the image/video enum, so the baseline of 3 applies. The description's phrase 'rough prompt' and 'generation prompt' loosely echoes the prompt parameter but adds no format, length, or content constraints.

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 (improve/enhance) and resource (a rough prompt) and states the concrete output — a detailed generation prompt. That is enough for an agent to separate it from generate_image and generate_video, though it never explicitly names those siblings, so it stops short of a 5.

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

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

There is no explicit when-to-use or when-not-to-use guidance, nor any named alternative. The 'Costs 1 credit' note gives a decision-relevant fact but does not tell the agent under which conditions enhancing is preferable to generating directly or to asking the user for a better prompt.

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

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

With no annotations, the description carries the full burden and does well: it discloses the 5-credit cost, the destructive consequence of using specPrompt (loses authenticity, discards the real frame), and the default behavior of 'prompt'. It does not mention auth requirements or rate limits, but the operational consequences are unusually well covered.

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

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

Four dense sentences, each front-loaded with the highest-value guidance first (what it does and its cost), followed by parameter routing and the key pitfall. 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 4-param tool with no annotations and no output schema, the description covers cost, inputs, defaults, and failure modes thoroughly. The only gap is that it says nothing about what the call returns (an image URL, render status, etc.), which an agent might need to proceed.

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

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

Schema coverage is 100%, so all four parameters are already documented in the schema. The description reinforces the roles of sourceImageUrl, faceImageUrl, prompt, and specPrompt, but adds little beyond what the schema descriptions already state, so it sits at the 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+resource: swapping an avatar's face onto a real hook frame. It is instantly distinguishable from siblings like generate_image or generate_video because it describes an image-to-image face compositing operation.

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 routing rules: ALWAYS use sourceImageUrl + faceImageUrl, only override 'prompt' when the user gives custom instructions, and NEVER put user instructions in specPrompt. When-to-use and when-not-to-use are both spelled out.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses two non-schema traits: the result is always persisted as an asset and it costs 5 credits. It stops short of permissions, failure/error behavior, or how the generated asset is retrieved afterward.

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

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

Three short sentences, zero filler, with the core purpose front-loaded ahead of the persistence and cost facts. Every sentence 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 4-parameter generation tool with no output schema and no annotations, the description covers purpose, persistence, and cost but omits how to obtain the resulting avatar, credit-check prerequisites, and model selection advice. Adequate but with clear gaps.

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

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

Schema description coverage is 100%, so each of the 4 parameters (model, prompt, avatarName, aspectRatio) is already documented, including enum values. The description adds no parameter-level syntax or defaults, 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 an AI avatar image from a text prompt.' The purpose is unambiguous. However, it never differentiates itself from the sibling generate_image, so an agent must guess which image-generation tool 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?

There is no when-to-use guidance, no prerequisites, and no mention of when to prefer generate_image or face_swap instead. The only context offered is that output 'Always saved as a persistent asset' and a credit cost, which inform the call but do not route the agent among 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?

With no annotations, the description carries the full behavioral burden. It usefully discloses cost (5 credits) and an input constraint, but omits whether generation is synchronous or async — a meaningful gap given the sibling get_render_status implies polling-style rendering — and says nothing about output location or failure 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 short clauses, each earning its place: scope, exclusion/alternative, and cost. The most decision-relevant routing info (what it is and what it isn't) is front-loaded.

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

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

For a 5-param generation tool with no annotations and no output schema, the description covers selection and cost but leaves return behavior and sync/async semantics unexplained despite a get_render_status sibling hinting at async rendering. Adequate but with clear gaps.

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

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

Schema description coverage is 100% with 3 enums, so the schema already documents model, resolution, aspect ratio, and referenceImageUrl. The description adds no parameter-level detail, so the baseline 3 applies. Mild tension: 'text prompt only' while referenceImageUrl exists for variations.

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 an image') plus a clear scope constraint ('from a text prompt only') with example use cases (scenes, backgrounds, product shots). It explicitly names the sibling it is not for (face_swap for avatar-on-hook), so an agent can distinguish it 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 an explicit when-not rule ('Do NOT use this for putting avatars on hooks') and routes the agent to the correct alternative tool by name ('use face_swap instead'). This is the strongest form of usage guidance — condition plus alternative.

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

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

With no annotations, the description carries the full behavioral burden and does well: it discloses credit cost and runtime per model tier, the 5-second default duration, and the timeout/save-recovery path via get_render_status. It does not describe authentication requirements or the exact shape of the returned asset beyond 'saved video asset'.

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, then packs model tradeoffs, default duration, failure recovery, and the prompt prerequisite into tight clauses with no filler. Every sentence carries actionable information for invocation.

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 six-parameter generation tool with no output schema, the description covers the key caller concerns: cost, latency, defaults, prerequisite prompt enhancement, and timeout recovery. It could add a bit more on the returned asset or where the video is stored, but nothing critical 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%, so the baseline is 3, but the description adds genuine meaning beyond the schema by attaching cost (10/25/30 credits) and latency (~30s, 1-2min, 2-3min) to each model enum value, plus confirming the 5-second default duration. The resolution and title parameters receive no extra semantic 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?

States a specific verb and resource ('Generate a video from a still image using AI'), which clearly separates it from siblings like generate_image, stitch_video, and scrape_video. An agent can identify the tool's function from the first sentence alone.

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

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

Explicitly routes the agent to alternatives under named conditions: use enhance_prompt first if the prompt is generic, and use get_render_status if the tool times out. It also guides model selection by cost and latency, giving concrete when-to-use criteria rather than leaving them 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?

No annotations are provided, so the description carries the full behavioral burden. It conveys that the tool returns usage instructions and mentions YOLO mode, but does not explicitly state that it is read-only, has no side effects, or how the instructions are returned.

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

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

Two sentences with no wasted words. The core action and trigger conditions are front-loaded and easy to scan.

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

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

For a simple, zero-parameter help tool with no output schema or annotations, the description provides enough context to call it correctly. It could add a brief note about what the instructions contain or the return behavior, but no critical information 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?

The tool takes zero parameters, so there are no parameter semantics to document. The description properly does not discuss parameters, and the baseline for a zero-parameter tool is 4.

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: retrieving YuzuGrow usage instructions, including YOLO mode. It clearly distinguishes itself from the many content-generation siblings, but does not explicitly name an alternative tool or scope boundary.

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 triggering conditions: when the user asks for help, says 'YOLO mode', or when the caller needs guidance on the tool flow. It lacks explicit when-not conditions or alternative tools, but for a help tool the usage context is well specified.

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

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

No annotations are provided, so the description must carry the behavioral load. 'Check ... by looking for new assets' implies a read/poll operation and the timeout context explains its purpose, but it never states that it is non-mutating, how/when to re-poll, or what the result looks like when nothing has completed.

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

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

Two short sentences with zero filler; the core action leads and the usage cue follows immediately.

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 should clarify what is returned, yet 'check if ... has completed' could mean a boolean, a status enum, or a list of new assets — the agent cannot tell. Given three parameters and no annotations, more context is needed.

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 67% and the description adds no parameter meaning: the type enum (HOOK/AVATAR/IMAGE/etc.), limit, and since are all undocumented in prose. 'Looking for new assets' only loosely gestures at the type/since filters without explaining them.

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

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

States a specific action and mechanism: check whether a requested generation has completed by scanning for new assets. It is clear what the tool does, though it never explicitly distinguishes itself from the sibling list_assets, which also returns assets.

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 concrete trigger condition — 'Use after generate_video if it times out' — which tells the agent when this tool is relevant. It stops short of naming alternatives or describing what to do if no new assets are found.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses the return format ('signed URLs'), which is real behavioral value for a read tool, but says nothing about auth requirements, ordering, or pagination behavior beyond the schema's limit field.

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 compact sentences with the core purpose front-loaded and no filler. The only waste is the imprecise type list, which repeats (and slightly muddies) what the schema already enumerates.

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-required-param list tool with no output schema, the description covers purpose and return type but omits guidance on filtering strategy or result limits. Adequate minimum viability, with clear gaps for an agent choosing among the many asset-generating siblings.

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 type, limit, and search are already documented in the schema. The description's asset-type examples add only marginal meaning and are actually less precise than the enum, so it does not exceed the schema 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?

Specific verb+resource ('List uploaded assets') with parenthetical examples of what counts as an asset. It does not differentiate from the closest sibling, create_upload_url, nor reconcile its examples with the schema enum (which uses HOOK/DEMO/SOURCE/FINAL rather than 'videos').

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?

No statement of when to use this versus alternatives like list_products or create_upload_url, no prerequisites, and no exclusions. Usage is only implied by the verb 'list'.

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

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

With no annotations, the description carries the full behavioral burden. 'For this account' hints at account scoping, but there is no mention of pagination, result limits, ordering, or auth requirements for a list that could return many rows.

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. It is efficient, though arguably too terse to carry any extra context an agent might need.

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

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

For a simple zero-parameter read tool this is minimally adequate, but with no output schema the description could say what a product entry contains or how results are bounded. The 'products/brands' duality is left unexplained.

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

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

The tool takes zero parameters, so there are no parameter semantics to clarify; the schema is trivially complete and the description adds nothing needed on this axis.

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 (products/brands) scoped to the account, which is enough for an agent to know what it returns. It does not distinguish itself from siblings like list_assets or create_product, though the verb/resource pairing 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?

No when-to-use guidance, no prerequisites, and no exclusion of alternatives. The agent must infer that this is the catalog-read tool; nothing routes it here versus create_product or update_product.

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

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

With no annotations, the description must carry the behavioral burden. It does add a genuinely useful constraint beyond the schema — never name competitors, use generic terms like 'language apps' — which is real behavioral guidance. However, it says nothing about output format, cost/credits, or whether the remix is generated fresh versus derived from the source hook.

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, zero waste. The core action comes first and the hard constraint is flagged with 'IMPORTANT' so it is unlikely to be skimmed past.

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

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

For a simple two-required-parameter generative tool with no output schema and no annotations, the description covers what it does and the main content constraint. It is adequate but silent on return shape and any credit/usage implications, which matter for an AI generation call.

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

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

Schema description coverage is 100% and both parameters (originalHook, productDescription) are documented in the schema, so the baseline is 3. The description adds no syntax, length, or format guidance for either parameter.

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

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

States a specific verb (remix) and resource (viral hook text) with the key qualifier 'for a different product using AI.' It does not distinguish itself from the related sibling analyze_hook, so an agent must infer the boundary, but the core purpose 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?

Usage is implied: use this to adapt an existing hook to another product. There is no explicit when-not guidance and no reference to sibling tools such as analyze_hook or suggest_captions, leaving the agent to infer the workflow position.

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

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

With no annotations, the description carries the disclosure burden and does well: it reveals the side effect (only the first frame is persisted), the omission of other artifacts, and the cost (0 credits). It does not state whether it writes to the database, auth requirements, or rate limits, but the cost and storage semantics are the operationally important traits here.

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

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

Four short sentences, each carrying distinct information: purpose, storage constraint, cost, and usage trigger. The primary action is front-loaded and 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 single-parameter scrape tool with no output schema and no annotations, the description covers what it produces, what it does not produce, cost, and when to call it. Return shape details (metadata fields) are unspecified, which is the only meaningful 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?

There is a single parameter at 100% schema coverage; the schema already documents the url field and supported platforms (TikTok, Instagram, YouTube). The description adds no format or validation detail beyond what the schema states, so a 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 (Scrape) and resource (a video URL) and names exactly what is produced: the first frame plus metadata. This is easily distinguished from sibling generators like generate_video or stitch_video, which create rather than extract.

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 concrete triggering conditions: a database result lacking cleanThumbnailUrl, or a user-supplied new URL. It also bounds behavior with 'No video clips or extra frames saved.' It does not name an alternative tool for the case where a full clip is actually needed, which is the only 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?

No annotations are provided, so the description carries the full behavioral burden. It implies a read-only lookup but discloses nothing about result format, pagination via 'limit', or whether the call consumes credits (relevant given the check_credits sibling).

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

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

A single tight sentence with the resource and the payoff front-loaded. No filler, nothing wasted.

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

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

For a five-parameter search tool with no annotations and no output schema, the description is too thin. It never says what a result contains, how results are ordered, or whether there is a cost, leaving real gaps for the agent.

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

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

Schema coverage is 100%, so all five filters (search, emotion, category, formatType, limit) are already documented in the schema. The description adds no syntax, format, or interaction detail beyond that, 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 (Search) and resource (curated viral video database) plus the intent (hook inspiration). It is distinguishable from scrape_video and analyze_hook, though it does not explicitly contrast itself with those 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?

The phrase 'for hook inspiration' hints at intent but gives no conditions for when to reach for this over analyze_hook, remix_hook, or scrape_video, and no prerequisites. An agent must infer routing entirely from the name.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses the credit cost and a mandatory user-confirmation step, but says nothing about permission needs, whether stitching is synchronous or async (dangling get_render_status suggests async), whether an existing projectName is overwritten, or what the call returns.

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

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

Three front-loaded sentences with no filler; the purpose and the confirmation gate are up front. Slightly verbose in restating the overlay question rather than referencing textOnDemo directly.

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 render-style tool with no output schema, the description covers the input-side essentials but omits the execution model (sync vs async render, result retrieval, failure behavior). With no output schema present, the description should indicate what a successful call yields.

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% across all 11 parameters, so the schema already documents each field. The description only reinforces the hook-vs-demo text distinction that textOnDemo already covers, 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?

States a specific verb (Assemble/stitch) and resource (hook + demo clips into a final vertical video), and names the output artifact. An agent can distinguish it from generate_video or remix_hook which produce 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?

Gives a concrete pre-invocation requirement ('ask the user whether the text overlay should appear on the demo section') and surfaces the cost (2 credits). It does not, however, compare against alternatives like remix_hook or generate_video for when stitching is the right choice.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses the output count (3 suggestions) but says nothing about credit consumption (a check_credits sibling exists), whether anything is posted or persisted, latency, or what happens when optional inputs are omitted.

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 or redundancy. It is efficient, though extremely terse given the absent annotations and output 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?

Two simple optional parameters and no nested objects keep the tool low-complexity, and the description implies a text output of three captions. However, with no annotations and no output schema, it should say more about what the three suggestions look like and whether inputs are required.

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%, with both hookText and productContext clearly documented in the schema, so the baseline is 3. The description adds no format, length, or tone guidance for either parameter, so it does not exceed 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 (Generate), resource (social media caption suggestions), quantity (3), and domain constraint (for a UGC video). No sibling tool overlaps on captions, so differentiation is implicit rather than explicit, which keeps it just 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?

There is no when-to-use guidance, no statement of prerequisites, and no alternative named among siblings like enhance_prompt or remix_hook. Usage is only inferable from the tool name and description.

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

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

No annotations are provided, so the description carries the entire behavioral burden. It says only that an existing product/brand is updated, with no mention of whether updates are partial, what gets replaced, required permissions, reversibility, or response 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?

The description is a single front-loaded sentence with no wasted words. It is concise, though arguably too terse for a mutation tool with four parameters.

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 annotations, no output schema, and a mutation operation, the description should do more to explain update semantics, partial-update behavior, and expected effects. As written, it is incomplete for an agent to call the tool with confidence.

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 id, url, name, and description. The description adds no parameter-level meaning beyond that, making the baseline 3 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 (Update) and resource (existing product/brand), and the word 'existing' distinguishes it from create_product. It does not explicitly name sibling alternatives, and 'brand' adds slight ambiguity, 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?

There is no explicit when-to-use guidance, no alternatives named, and no exclusions. The word 'existing' implies it is not for creation, but an agent gets no routing instructions relative to create_product or list_products.

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