Keyframer

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

Annotations only indicate this is not read-only, not idempotent, and not destructive. The description adds substantial behavioral context: it validates first, creates a public guest scene with QR when no key is provided, persists the scene after signup/Remix, and enforces account limits for keyed saves. This goes far beyond what annotations convey.

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 dense but efficient: three sentences front-load the primary outcome, then validation, then guest-versus-key behavior. Every clause carries operational information, and there is no filler or repetition of the 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 creation tool with no output schema and minimal annotations, the description is remarkably complete. It covers the return value (editor URL), the validation step, guest persistence and QR behavior, account behavior with limits, and the role of signing up/remixing. An agent has enough context to invoke it correctly and set expectations.

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 all three parameters: name default, scene format with a pointer to get_scene_format, and make_public sharing behavior. The description adds no parameter-specific detail, so the baseline of 3 applies.

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

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

The description states a specific verb and outcome: 'Save a scene and get an editor URL where it opens in the visual editor.' This clearly distinguishes create_scene from siblings like validate_scene or update_scene by emphasizing creation plus the editor-URL result.

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 gives clear usage conditions around authentication: works without a key as a public 24-hour guest scene, or with a key saving to an account with limits. It does not explicitly say 'use update_scene for existing scenes' or 'use validate_scene if you only want validation,' 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?

Beyond the readOnlyHint annotation, the description adds valuable behavioral context: deterministic execution, no AI, no credit usage, API key requirement, and the output target distinction between Reanimated v4 and the reduced-feature 'animated' core API. These details help an agent set expectations correctly without contradicting the annotation.

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 three tight sentences with no filler. It front-loads the core purpose, then covers input modes, output targets, cost model, and access requirements, with every sentence earning 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 tool with five optional parameters and no output schema, the description covers the key operational facts: what it does, how to provide input, what output target is used, and the access constraint. It does not explicitly state that the result is a code string or describe failure modes, but the description together with the rich schema is sufficient for correct usage.

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 input schema already documents all five parameters with 100% coverage, so the baseline is 3. The description adds meaningful context by explaining the two input modes (inline JSON vs scene_id) and clarifying that 'animated' uses a reduced feature set, which enriches the api parameter semantics beyond the schema enum descriptions.

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 clearly states the tool compiles a scene into a runnable React Native component, which is specific and unambiguous. It does not explicitly name sibling tools or contrast itself with them, so the differentiation is implied rather than stated.

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

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

The description gives clear context for when to use the tool: when you want to compile a scene into React Native code, and you can pass inline JSON or a saved scene_id. It also communicates prerequisites and cost characteristics (API key on a paid plan, no AI, no credits), but it does not explicitly list exclusions or alternative 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?

The readOnlyHint annotation already establishes safety, and the description adds useful behavioral detail: scanning runs the scene live, edits sync as they happen, and authentication requirements vary by scene visibility. This goes beyond the annotation without contradicting it.

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 with no filler: the first identifies the deliverable, the second explains the preview behavior, and the third covers authentication. The key information 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?

The definition is adequate for a single-parameter, read-only tool: it describes the output, the on-device behavior, and auth requirements. There is no output schema, but 'terminal-scannable QR code' sufficiently conveys the return payload for this use case.

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 input schema provides 100% coverage for scene_id, including a helpful source hint ('from create_scene or list_scenes'). The description adds no parameter-specific meaning, but the schema already carries that burden effectively.

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 clearly states that the tool produces a terminal-scannable QR code for a scene and explains what the QR code does. It is distinct from scene retrieval siblings by focusing on live device preview, though it does not explicitly contrast itself with a named alternative.

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 actionable context: public and guest scenes work without a key, while private scenes require an API key on a paid plan. It does not explicitly name alternate tools or exclusion conditions, but the intended use case is clear.

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 provide readOnlyHint, so the safety profile is covered. The description adds meaningful behavioral detail beyond that: it specifies the return payload (metadata, scene JSON, generated React Native Reanimated code), says the scene JSON can seed create_scene, and clarifies licensing with 'Recipe code is free to use.'

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-load the action and resource, then pack the payload and licensing into the second sentence. There is no filler or redundant restating of the schema.

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

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

For a read-only single-resource fetch with a fully documented schema, the description states the return payload, the integration point with create_scene, and usage rights. With readOnlyHint and 100% schema coverage, nothing essential 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 input schema covers all four parameters with descriptions, so the baseline 3 applies. The description confirms slug as the lookup key and only implicitly reflects include_code's effect; it adds 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?

Begins with 'Fetch one recipe by slug', naming a specific verb, resource, and key identifier. It enumerates the payload (metadata, scene JSON, React Native Reanimated code), and the mention of create_scene separates recipes from plain scenes. This distinguishes it well from get_scene and search_recipes.

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 'one recipe by slug' plus the parameter note that slug comes from search_recipes gives a clear retrieval context. Though the description does not explicitly name alternatives or when-not conditions, no exclusions are needed for such a straightforward fetch.

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

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

Annotations already declare readOnlyHint=true, and the description is consistent with a read operation. It adds useful behavioral context beyond the annotation: the tool can access public scenes, returns JSON, requires an API key, and supports integration with update_scene and generate_code.

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 no filler. The core purpose and output type are front-loaded, and the API key requirement and typical downstream uses are stated efficiently.

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 low-complexity read-only tool with one fully documented parameter, the description is largely sufficient: it states the return format, access scope, and prerequisite. It could mention error cases or whether the response has a particular structure, but no output schema exists and the essential usage 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?

Schema coverage for the single 'id' parameter is 100%, and the schema already explains the id's provenance (list_scenes or editor URL). The description adds no extra parameter semantics beyond what the schema provides, 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?

Clearly states a specific verb ('Fetch') and resource ('one of your scenes or any public scene') with the return format (JSON). The use cases mentioned also distinguish it from list_scenes (single scene by id) and from update_scene/generate_code (which consume or modify the fetched result).

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 context: fetch a scene when you have its id and want JSON, either to edit or feed elsewhere. It notes the API key requirement, but does not explicitly exclude alternatives like list_scenes for enumeration or get_scene_format for format details.

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

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

The readOnlyHint annotation already covers the read-only safety profile, and the description adds useful context about the guide's content organization. It does not describe the exact return format or whether output is markdown, text, or structured JSON, but for a documentation tool this is not a major 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?

Two sentences deliver the core purpose, usage timing, section map, and key content examples with no filler. The most important guidance ('read this before authoring a scene') 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 one-parameter documentation tool with a read-only annotation, the description covers the essential sections and content boundaries. It leaves unstated what the tool actually returns, and since there is no output schema the description could have been slightly more explicit, but the purpose is still clear enough for correct invocation.

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

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

The schema already documents the single optional section parameter with a default and enum, so the baseline is 3. The description adds real value by explaining what each enum value actually contains: 'scene' covers elements/keyframes/easing, while 'nodes' covers procedural animation graphs, clocks, springs, and repeaters.

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 clearly identifies the tool as an authoring guide for the Keyframer scene JSON format, not a scene fetch or mutation operation. It distinguishes itself from the sibling get_scene by focusing on the format and schema documentation.

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

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

It explicitly says to read this before authoring a scene, giving a clear temporal placement relative to create/update/validate tools. It does not explicitly name alternatives or exclusions, but the 'before authoring' context is sufficient for typical use.

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

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

The readOnlyHint annotation already covers safety, so the description adds useful behavior beyond that: it discloses the API key requirement, scopes results to the connected account, and names the returned fields. Pagination or list limits are not mentioned, but this is a minor gap for a zero-parameter read tool.

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

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

The description is a single, front-loaded sentence that delivers action, resource, scope, output fields, and auth requirement in that order. There is no filler, repetition, or unnecessary detail.

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

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

For a simple read-only list tool, the description is nearly complete: it identifies the auth requirement, the scope, and the fields returned. The main omission is any note about pagination or result limits, which could matter for accounts with many scenes.

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

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

The tool has zero parameters, so the schema is trivially complete and the description does not need to compensate. The baseline of 4 applies because there are no parameters whose meaning could be clarified.

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 opens with the specific verb 'List' and identifies a clear resource: scenes in the connected Keyframer account. It also names the returned fields, making it easy to distinguish from siblings like get_scene, create_scene, and update_scene.

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

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

The description implies this is the default way to enumerate scenes in the account, but it does not explicitly state when to choose list_scenes over get_scene or search_recipes. It also provides no exclusion conditions or 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 mark readOnlyHint=true, and the description reinforces this with 'Free to call' and positions it as a pre-flight check before a mutating sibling (create_scene). It adds valuable context beyond the annotation by stating it runs 'the same math the editor preview runs', which signals the output is faithful to the actual render, and clarifies that it only reports 'moving' props.

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 with zero filler. The core purpose is front-loaded, the contrast with validate_scene is packed into the second sentence, and the workflow guidance is a compact one-liner. 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?

Despite no output schema, the description tells the agent what the return shape looks like (value series per moving prop), how faithful it is (same math as editor), when to use it (motion checking before create_scene), and that it is safe to call repeatedly. Combined with the fully described parameters and read-only annotation, nothing essential is missing for correct invocation.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds little parameter-specific meaning beyond the schema; it references 'N evenly spaced times' which maps to samples, and 'each moving prop' hints at element_ids, but it does not define defaults, formats, or filtering behavior beyond what the schema already states.

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 opens with a specific verb and resource: 'Numerically preview a scene' and explains exactly what it evaluates (keyframes AND node graphs) and returns (a value series per moving prop). It also distinguishes itself from validate_scene, making the purpose unmistakable even among ten 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?

Usage context is explicit: it says validate_scene checks structure while this checks MOTION, and lists concrete confirmations (ranges, spring overshoot, stagger offsets, elements actually move before create_scene). It even provides workflow guidance ('Free to call — iterate: author → sample → adjust'), which tells the agent exactly when and how often to invoke it.

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

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

Annotations already declare readOnlyHint=true, and the description adds useful behavior beyond that: each recipe contains a scene plus verified React Native Reanimated code, and the tool returns slugs for get_recipe. This gives an agent meaningful expectations about the tool's output and content, though it doesn't cover edge cases like empty results or search matching semantics.

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 concise: two sentences, front-loaded with the core purpose and enriched with useful examples. Every clause adds value, and the 'Returns slugs for get_recipe' clause efficiently ties the tool to its sibling workflow.

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 search endpoint, the description covers the key elements: what is searched, what a result contains, and what the output is for. There is no output schema, so the explicit 'Returns slugs for get_recipe' is especially helpful. It could be more complete by noting behavior when no recipes match or how limit interacts with results, but these are minor 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 only 33%, covering just query. The description does not compensate for the unexplained limit and category parameters, nor does it add meaning beyond the schema's query example. An agent would need to inspect the schema to understand limit bounds and category options, leaving a notable gap.

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 ('Search') and a specific resource ('150+ free Keyframer recipes'), and lists concrete examples like bounce, carousels, and shaders. It also clearly differentiates the tool by noting it returns slugs for get_recipe, so an agent can understand its role versus 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 description clearly implies the workflow: search recipes to find candidates, then use get_recipe with the returned slugs. It does not explicitly state when not to use this tool or compare it to siblings like generate_code, but the 'Returns slugs for get_recipe' line provides solid use-context.

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 mark this as non-read and destructive; the description adds complementary context by stating the replacement is full-scene, that live previews observe the change, and that API-key auth and ownership apply. No contradiction with the destructiveHint.

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, front-loaded sentences, each carrying distinct information: core operation, iteration purpose, and constraints (live preview, API key, ownership). 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 destructive update tool with four params and no output schema, the description supplies the essential operational context: full replacement, validation, live preview side-effects, auth, and ownership. The schema covers parameter details and get_scene_format covers scene shape.

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

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

Schema coverage is 100%, so baseline is 3, but 'full scene JSON, validated first' clarifies that scene is a whole replacement rather than a patch, and 'own scenes only' reinforces the scene_id ownership. This adds meaning beyond the field descriptions.

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 opens with a precise verb and resource: 'Replace the content of one of your scenes.' It also signals the edit-loop nature ('iterating instead of duplicating'), which distinguishes it from create_scene and other siblings without needing their 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?

It clearly contextualizes use: iterating on an existing scene instead of duplicating, and limits to own scenes. It implies validation before replacing and live-preview consequences, though it does not explicitly name validate_scene or get_scene in this definition.

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

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

Annotations already declare readOnlyHint=true, so the description doesn't need to restate that. It adds value by specifying the return type ('errors (must fix) and warnings (advisory)') and the cost-free nature, going beyond annotations without contradicting them.

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 with zero fluff. The action is front-loaded, the purpose is immediately clear, and the iteration hint is a valuable additive detail. 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 simple one-parameter, read-only validator, the description covers purpose, usage timing, return types, and how to proceed. It even references a sibling tool for shape details. Nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is 100% and the parameter description is rich, offering type alternatives and pointing to get_scene_format for shape. The tool description itself doesn't add parameter details, but the schema already provides excellent guidance, so this exceeds the baseline for high coverage.

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 clear verb ('Validate'), a specific resource ('a scene against the Keyframer format'), and explicitly ties it to subsequent actions ('before create_scene or generate_code'). It distinguishes itself from siblings by framing validation as a gate for those operations.

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 says when to use the tool ('before create_scene or generate_code') and even provides iteration guidance ('Free to call — iterate until clean'). This leaves no ambiguity about its role relative to sibling tools.

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