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

No annotations are provided, so the description carries the full burden of disclosing behavior. It reveals some parameter conventions (angle orientation, height scale, lens units) and implies the action of framing, but it does not state whether this overwrites the current camera, applies to a specific target, persists across renders, or has any side effects. For a mutating tool with no annotation coverage, this is insufficient.

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 compact and front-loaded: the primary verb and available composition types appear first, followed by terse parameter hints. The Korean fragment (카메라 구도) is somewhat redundant and the style is telegraphic, but overall there is minimal fluff and the key semantics are packed 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?

With 6 parameters, no annotations, no output schema, and zero schema descriptions, the description needed to cover all parameter meanings and usage context. It covers several numeric conventions and preset names, but leaves target and distance_factor unexplained, provides no usage guidance, and does not clarify how parameters combine. This is incomplete for reliable invocation.

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

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

Schema description coverage is 0%, so the description must compensate. It adds real value by defining preset values, angle_deg (0=front, 90=right, -90=left), height (0=bottom, 1=top), and lens units (mm). However, target and distance_factor are not explained at all, and the interaction between preset, angle, height, and lens is left unclear.

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 action ('Frame the shot') and enumerates composition styles (wide, medium, closeup, low, high, top, front or side), with a Korean phrase confirming camera composition. It is not a tautology and it communicates the tool's role. However, it does not explicitly say it sets/updates camera parameters, and it does not distinguish itself from sibling tools like set_look or camera_shake.

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

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

There is no guidance about when to use camera versus alternatives such as set_look, camera_shake, or snapshot. The description implies it is for framing a shot, but it offers no conditions, exclusions, or contrast with sibling tools. With many camera-related siblings, this lack of routing guidance is a notable 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?

The description discloses the settling behavior over time and provides strength scale guidance, which adds context beyond the schema. However, with no annotations provided, the description carries the full burden for behavioral disclosure. It doesn't mention whether the shake is applied to the current frame, whether it modifies the camera permanently, or how it interacts with other camera tools.

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 short and front-loaded with the core behavior. The Korean translation is somewhat redundant but adds the strength scale detail. It earns its place by providing the key parameter guidance, though it could be slightly more structured.

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 4 parameters, 0% schema coverage, no annotations, and an output schema present, the description is incomplete. It explains only strength and leaves seed, frame, and duration undefined. An agent would need to infer or experiment to understand the full calling contract.

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

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

Schema description coverage is 0%, so the description must compensate for the four undocumented parameters. It only explains 'strength' with example values (0.1, 0.3, 0.8) and mentions 'm 단위' (meters). It does not explain seed, frame, or duration, leaving the agent to guess their meanings and defaults.

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

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

The description states a specific verb and resource: 'Shake the camera at an impact, settling down over time.' This clearly distinguishes it from sibling tools like camera, set_look, and set_timing. The Korean phrase adds a bit of redundancy but doesn't obscure the purpose.

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

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

The description implies usage context ('at an impact') and provides strength guidance (0.1 slight, 0.3 normal, 0.8 strong), which helps an agent choose appropriate values. However, it doesn't explicitly state when to use this tool versus alternatives like camera or set_timing, nor does it mention any exclusions.

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 Korean text ('다음 도구 호출 때 다시 굽는다') adds an important behavioral consequence: caches are re-baked on the next tool call. This goes beyond the simple 'clear' statement and is valuable since no annotations are provided. However, this key behavior is only present in the Korean portion, and the English text omits 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?

The description is short but contains redundant bilingual text that is not identical. The English and Korean versions differ in content (English lacks the re-bake behavior and 'cache folders'), making it less clean and potentially confusing for an English-only reader.

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 parameters and an output schema present, the description covers basic purpose, but it leaves out usage guidance and hides a key lifecycle behavior in the Korean text. An agent could miss a significant consequence of calling this tool.

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

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

The tool has zero parameters, so the description does not need to explain parameter meaning. The baseline of 4 applies and there are no ambiguities to compensate for.

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 ('Clear baked caches') and a goal ('free disk space'), using a clear verb and resource. It is distinct from sibling tools like snapshot, restore, and reset_destroy, so an agent can differentiate it without opening 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?

No explicit guidance is given about when to use this tool versus alternatives. It mentions freeing disk space as a benefit, but there are no conditions, prerequisites, or exclusions to direct the agent's 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 must convey behavioral transparency. It describes the visual result—flapping cloth flag—and the meaning of 'at', but it does not disclose whether the tool creates an object, modifies the scene, requires existing geometry, or produces a preview.

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 short and starts with the essential visual concept, but it includes a Korean translation that repeats the English sentence, adding no new information for an English-speaking agent. The note about 'at' is useful but the redundancy makes the structure imperfect.

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 six optional parameters, no annotations, and no output schema, the description is too thin. It identifies the object and one parameter, but fails to explain the tool's action, the meaning of animation/timing parameters, or what the agent should expect as a result.

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

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

Schema description coverage is 0%, so the description must compensate for six parameters. It only explains 'at' as the position at the base of the pole; width, height, wind_strength, frames, and preview_frames are left to inference from their names, with frames and preview_frames remaining ambiguous.

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 resource: a cloth flag on a pole flapping in the wind. It is not a tautology and conveys the visual purpose, though it lacks an explicit verb like 'create' or 'spawn' to state what action the tool performs.

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

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

There is no guidance on when to use this tool versus alternatives such as wind, particles, or other scene-creation tools. The only hint is about the 'at' parameter, which is a parameter note, not usage 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?

With no annotations, the description carries the full behavioral disclosure burden. It reveals that the operation is a physics simulation with Voronoi chunks, mentions that preview frames are returned, and explains the 'volume_kept' metric as a validity check. It does not explicitly state side effects like irreversibility or whether the original mesh is preserved, but the name 'destroy' plus the physics description convey the core 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 compact list of parameter explanations, which is appropriate for a tool with 23 parameters. However, it duplicates the English summary in Korean, wasting a sentence. Some entries could be integrated (density/friction/bounce are combined), but overall it is relatively tight for its size.

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 covers the main purpose, result metric, and many parameter effects, but with no output schema, it should clarify all inputs and outputs. Six parameters are unexplained, and the description does not mention prerequisites, execution time, or scene side effects. For a complex 23-parameter tool, this is a notable gap, though the included notes on performance and physical correctness add value.

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 has 0% parameter description coverage, so the description must compensate. It explains 17 of 23 parameters, including enums, recommended ranges, and behavioral effects (e.g., 'impact_power: 충격체 무게 = 대상 전체 무게 × 이 값', pieces count affects speed). However, six parameters (dust, frames, seed, time_scale, impact_height, preview_frames) are left undocumented, and most explanations are in Korean, which may reduce accessibility for English-only agents.

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 first sentence states a precise action: 'Fracture any mesh into Voronoi chunks and collapse it with real physics.' This clearly distinguishes it from siblings like 'explode' or 'water' by specifying the Voronoi fragmentation and physics collapse. It also adds a scope note, 'Works on imported models,' which further narrows the resource type.

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 provides no explicit guidance on when to use this tool versus alternatives such as 'explode' or 'reset_destroy'. It mentions 'Works on imported models' but that is a constraint, not a usage rule. There are no exclusions or alternative tool names, so the agent must infer usage context from the tool name alone.

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 states the action is to 'check' prerequisites, implying a read-only diagnostic, but it does not disclose what happens on failure, whether any fixes are applied, or what the output contains. The output schema covers return details, but side effects and failure modes are not mentioned, leaving a moderate 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?

The description is short and front-loads the key object list. However, the Korean sentence '준비물 점검. 뭔가 안 될 때 먼저 부른다.' essentially repeats the English, adding redundancy. It remains compact and to the point, but the duplication prevents a top score.

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

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

For a zero-parameter diagnostic tool with an output schema present, the description adequately explains what is checked and when to invoke it. It does not need to detail return values because the output schema exists. It could have added executor prerequisites, but this is a minor omission, so a 4 is appropriate.

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 has zero parameters and schema coverage is 100%, so there are no parameters to describe. According to the rubric, 0 params gets a baseline of 4. The description also lists the checked items, which gives context about what the tool inspects even though they are not formal parameters.

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 ('Check') and names the exact resources (python, mcp, uv, Blender, receiver add-on, connection, output folder). This clearly distinguishes it from siblings like ping_blender, which only checks Blender connectivity, and the 'call first when something doesn't work' adds a distinct diagnostic role.

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

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

Gives an explicit when-to-use: '뭔가 안 될 때 먼저 부른다' (call first when something doesn't work). This provides clear context for selecting the tool, though it does not name sibling alternatives or exclusion conditions, so it falls short of a full 5.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It is transparent about the destructive fracture behavior, the conditional smoke/fire-only mode, the performance cost of smoke_collision, and the effect of power and resolution settings. It does not mention persistence, cleanup, or other scene side effects, but core behavior is disclosed.

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 compact and front-loaded with the English summary, followed by concise Korean explanations of key parameters. The bilingual repetition adds some redundancy, but the content is terse and every sentence conveys useful information.

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

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

This is a 15-parameter creative tool with no annotations, no output schema, and no enum constraints. The description covers core behavior and a handful of presets, but omits many parameters that affect the result. An agent would be able to trigger a simple explosion but not reliably fine-tune it or anticipate full effects.

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

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

Schema description coverage is 0%, so the description must compensate. It adds useful meaning for `target` vs `at`, and gives presets for `power`, `resolution`, and `smoke_collision`. However, 10 of 15 parameters such as `dust`, `glue`, `frames`, `pieces`, `radius`, `pattern`, `material`, `burst_frame`, and `preview_frames` remain unexplained, leaving a significant 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 and resource: fracture the target, blow chunks outward, and add smoke/fire. It also explains the fallback behavior when no target is provided, which makes the tool's purpose clear. However, it does not explicitly name or differentiate siblings like fire/smoke/destroy.

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 decision-relevant context: if a target is provided, fracture it; if not, create smoke and fire at the `at` position. This helps the agent choose the right mode. It stops short of explicitly saying when not to use this tool versus alternatives like fire or smoke.

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 provided, the description carries the full behavioral burden, and it does so well: it discloses that .abc bakes water and piece motion per frame, that bake_physics bakes piece physics to keyframes irreversibly, and that smoke/volume is not exported in any format. These are non-obvious side effects and limits an agent needs to know.

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 reasonably short and front-loads the supported formats in the first sentence. However, there is some redundancy between the English '.abc also carries the animated water surface' and the Korean sentence restating that water and piece motion are baked, and the second sentence partly repeats the first.

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 three parameters and no annotations, the description covers the important behavioral nuances, irreversible baking, and the smoke limitation. The main gap is the undocumented names parameter, but because names is optional and the output schema exists, the definition is otherwise sufficient 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 description coverage is 0%, so the description must compensate. It richly explains bake_physics and implies that the path extension selects the format, but it does not explain the optional names parameter at all. The required path is intuitive, but one of the three parameters remains semantically opaque.

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 ('Export'), the resource (scene/model), and concrete target formats (glb/gltf/fbx/obj, .abc). It clearly distinguishes this from sibling tools like import_model or render_video by focusing on file-format export.

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 conditions for choosing .abc when animated water surface or baked piece motion is needed, warns that bake_physics is irreversible and recommends snapshot first, and explicitly states that smoke/volume is never exported. It does not name alternative sibling tools for those exclusions, but the guidance is concrete and actionable.

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 discloses meaningful traits: target-surface vs point burning, resolution=0 auto-scaling to object size, and per-parameter effects for density, dissolve, vorticity, and noise. However, it omits other behaviors like what happens when both target and at are set, or how frames are sequenced.

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 front-loaded English sentence is clear, but the Korean passage largely restates and extends the same content, creating bilingual redundancy. The content is informative but not tightly structured, and a mixed-language description adds parsing overhead for an agent.

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

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

For a 14-parameter simulation tool with no annotations and no output schema, the description leaves half the parameters unexplained and offers no guidance on return values, fire's interaction with the scene, or render requirements. This is a significant gap for a complex tool.

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

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

With 0% schema coverage, the description must compensate, and it explains 7 of 14 parameters (target, at, resolution, density, dissolve, vorticity, noise) with genuinely useful semantics, e.g. 'dissolve 사라지는 속도(클수록 오래 남음)'. But power, radius, frames, start/end_frame, preview_frames, and smoke_collision remain undocumented in both schema and description.

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

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

The English sentence states a specific verb and resource: 'Continuous fire with smoke, burning on a target's surface or at a point.' This conveys the primary effect and its two placement modes, distinguishing it from sim siblings like water, smoke, and explosion by its fire focus, though it never explicitly names alternatives.

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 explains the behavioral modes (target surface vs at point) but never tells an agent when to prefer fire over sibling simulation tools such as smoke, explosion, water, or splash. There is no explicit 'use when' guidance, no exclusions, and no 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?

With no annotations, the description carries the behavioral burden, and it delivers meaningful context: supported file formats, mesh joining, ground placement, size scaling behavior, and a cleanup/verification workflow. It does not mention error cases or permissions, but it discloses the most important behavioral traits beyond the schema.

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

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

The description is short and front-loaded with the core behavior, but it repeats the same statement in English and Korean, which is redundant. The size explanation and destroy workflow are useful, but the structural organization is a bit disjointed and could be tightened.

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

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

For a 5-parameter import tool with no output schema and no annotations, the description covers the main behavior, file formats, size semantics, and post-import inspection/destroy step. It remains incomplete because it does not document center, on_ground/name behavior, return values, or failure handling, so an agent gets adequate but not fully self-sufficient guidance.

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

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

Schema description coverage is 0%, so the description must compensate for parameter meaning. It explicitly documents 'size' and implies on_ground via 'stand it on the ground,' but it leaves path, name, and especially center undocumented. The agent must infer the semantics of several parameters from their titles alone.

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 a specific action, resource, and behavior: 'Import a 3D model... join it into one mesh and stand it on the ground.' It lists supported formats and distinguishes itself from related siblings like export_model and inspect_mesh, so an agent can identify the right tool.

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 a follow-up workflow ('가져온 뒤 inspect_mesh 로 상태를 보고 destroy 한다' – after importing, inspect with inspect_mesh then destroy), which helps with usage context. However, it does not explicitly state when to choose this tool over alternatives or when not to use it, leaving comparison to sibling tools implicit.

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

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

With no annotations, the description must carry the transparency burden. It lists what the tool inspects, implying a read-only operation, and 'repair preview' suggests it does not modify the mesh. However, it does not explicitly state that it has no side effects or whether it can fail. Partial disclosure but acceptable given the name and wording.

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 repeats the same information in Korean after the English text, adding redundancy without new value. The first sentence is concise and front-loaded, but the repetition lengthens it unnecessarily, reducing conciseness.

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?

While the purpose and usage context are clear, the complete lack of parameter documentation makes it incomplete. The output schema exists, so return values are covered, but an agent cannot correctly call the tool without understanding what to pass in. The description does not compensate for the low schema coverage.

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

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

Schema coverage is 0% and the description does not mention either parameter ('target' or 'decimate_to') at all. An agent has no idea what these parameters mean or how they affect the inspection, which is a critical gap for correct invocation.

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 a specific verb ('diagnose') and resource ('mesh') with the explicit context of being called before fracturing. It lists concrete checks (closed, volume, concavity, face count, repair preview) that distinguish it from destructive siblings like 'destroy' and 'explode'.

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 explicitly says 'before fracturing' and 'destroy 전에' (before destroy), giving a clear temporal trigger. It also adds a use case ('when you bring someone else's model'). It does not explicitly exclude any alternative, but the context is strong enough to guide selection.

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 communicates a read-only listing and specifies output units in meters, but it does not explicitly state non-mutation, empty-scene behavior, or whether hidden objects are included. Adequate but not rich.

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?

Short and front-loaded: the English sentence states the core operation and the Korean sentence adds scene context and use case. The bilingual restatement is slightly redundant, but both sentences earn their 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?

Given zero parameters and an existing output schema, the description is complete for a simple list tool. It covers what is returned, the units, and when to use it; 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 has zero parameters, so the schema already covers all input semantics. The description adds useful output context by mentioning names and sizes, which is the appropriate baseline for a parameterless tool.

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?

Description uses a specific verb 'List' plus resource 'mesh objects' and names the expected fields ('names and sizes'), so an agent knows exactly what it returns. The Korean sentence adds that it is used for choosing an effect target, which distinguishes it from sibling tools that perform actions or rendering.

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

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

Explicitly states when to use: '효과의 target 을 고를 때 쓴다' (used when choosing the target of an effect). It provides clear context but does not mention alternatives or exclusions, so it stops short of a 5.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'List saved snapshots' and does not disclose what a snapshot is, where they are stored, whether the list is sorted, whether it includes metadata, or whether any side effects occur. The bilingual text is redundant and does not add behavioral context.

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 short and front-loaded with the core statement, but the Korean duplicate ('저장해 둔 스냅샷 목록.') is redundant for an English-language tool description and adds no information. It is concise but not optimally structured; one sentence would suffice.

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 tool has an output schema, so return values may be documented there, but the description still lacks context about what 'snapshots' are in this domain, how they relate to sibling tools like 'snapshot' and 'restore', and whether listing has any side effects. For a tool with no annotations and no parameter guidance, the description is too thin to fully orient an 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?

The tool has zero parameters, so there is no parameter semantics burden on the description. The schema is trivially complete (100% coverage with no properties), and the description correctly implies a no-argument listing operation. Baseline 4 is appropriate for a zero-parameter tool.

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 and resource ('List saved snapshots'), so an agent can tell it is a read-only listing operation. However, it does not distinguish it from the sibling tool 'snapshot' or from 'restore'/'save_blend', which are related snapshot operations. The bilingual repetition adds no semantic value.

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 is given about when to use this tool versus alternatives like 'snapshot' or 'restore'. The description simply states what it does, leaving the agent to infer that it is for browsing saved snapshots. There is no mention of prerequisites, typical use cases, or exclusions.

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 provided, the description carries the behavioral disclosure burden. It discloses that the tool creates a building, ground, camera, and light, and that it returns one preview frame. However, it does not mention side effects on an existing scene, whether objects are appended or replaced, or any prerequisites, so some behavioral context is missing.

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 compact and front-loads the core purpose before parameter notes. The English and Korean sentences partially duplicate each other, adding mild redundancy, but the overall size is still reasonable and the key usage hint is preserved.

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?

Given that all 8 parameters are optional with defaults and there is no output schema, the description provides enough to call the tool: it explains the scene contents, the return value, the main style/ground choices, and the intended use case. It could be more complete about output format and scene interaction, but it is not critically incomplete.

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

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

Schema description coverage is 0%, so the description must compensate. It adds useful meaning for 'style' (plain vs. windows, with actual cut-out walls) and 'ground' (enumerated surface options, blank means default). But remaining parameters like width, depth, floors, floor_height, and windows_per_side get no explanation beyond their names, and units/constraints are not 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 states a specific action: 'Create a practice building with ground, camera and light' and notes it returns one preview frame. It also distinguishes this tool from destruction/editing siblings by saying it is used when there is no object to destroy.

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 Korean text explicitly says to use this when there are no destructible objects, which gives a clear usage context. It does not name specific alternative tools or state when not to use it, so it falls short of a fully explicit when/when-not comparison.

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 description discloses one behavioral trait (hides the flat ground) but with no annotations, the description carries the full burden. It omits important behaviors such as whether it creates a persistent object, how animation interacts with frames, whether it is destructive, and performance implications.

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 very brief and front-loaded with the core purpose, followed by a side effect and compact parameter hints. It contains no fluff, though the Korean text may be redundant for some agents, it contributes semantic value without bloat.

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 six parameters, no output schema, and no annotations, the description provides only the basic purpose and two parameter hints. It fails to explain the remaining parameters, return behavior, or relationship to sibling tools, leaving significant gaps 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 description adds meaning for only two of six parameters: size (width in meters) and wave_scale (calm/normal/rough). With 0% schema description coverage, it must explain all parameters; frames, choppiness, wind_velocity, and preview_frames remain completely unexplained.

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 ('Animated ocean surface') and a side effect ('Hides the flat ground while it exists'), which gives a clear purpose. However, it does not explicitly differentiate itself from the sibling tool 'water', leaving some ambiguity about which surface tool to choose.

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 is given on when to choose this tool over alternatives such as 'water', 'splash', or 'set_ground'. Usage must be inferred entirely from the name and brief description, which is insufficient for an agent facing many similar scene 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?

With no annotations, the description carries the full burden of behavioral disclosure. It does add useful behavior: it explains kind values, particle parameter meanings, and the important rule that negative/zero values keep the preset. It does not mention side effects, persistence, cleanup, or whether particles are transient visual effects.

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 compact and front-loaded with the core particle types before parameter notes. The brief English/Korean repetition is minor and does not obscure the content. It stays appropriately short for the amount of information it conveys.

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

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

For a complex 14-parameter tool with no annotations and no output schema, the description is incomplete. Missing details include the meaning of target, frames, area, height, start_frame, and preview_frames, as well as coordinate units, whether the effect is temporary or persistent, and what the agent should expect after 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 provides 0% parameter descriptions, and the tool has 14 parameters. The description explains only six of them: kind, size, gravity, drag, lifetime, and speed. Critical parameters such as at, area, count, frames, height, target, start_frame, and preview_frames remain unexplained, leaving significant gaps for an agent.

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 names the resource (particles) and enumerates the specific variants it handles: rain, snow, sparks, and ash. This is clear enough for an agent to understand what the tool produces, though it lacks an explicit verb like 'create' or 'spawn' and does not differentiate it from sibling effect tools such as fire or smoke.

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 by the listed particle kinds: if you want rain, snow, sparks, or ash, this tool is relevant. However, there is no explicit statement about when to use this versus sibling tools like fire, smoke, water, or splash, and no exclusions are provided.

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 full responsibility for behavioral disclosure. It only restates the tool's purpose and does not mention what happens when the connection is down, whether the check has side effects, whether it waits or times out, or what kind of response the agent should expect. For a network connectivity check, this is a meaningful 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?

The description is extremely concise and front-loaded: a single English sentence conveys the entire purpose. The Korean sentence is a direct translation and adds no new information, but it is not padding in a bilingual tool context. There is no wasted English prose.

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 connectivity check, the description captures the core intent. An output schema is present, so return-value details do not need to be repeated in the description. The only minor gap is the lack of clarification about whether this is a lightweight existence check or a full handshake, but this is not critical for invoking the tool correctly.

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

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

The tool has zero parameters and the schema fully documents this with 100% coverage. There is nothing for the description to add about parameter meaning or constraints, so the baseline of 4 is appropriate.

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

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

The description states a specific verb ('check') and a specific resource ('the socket connection to Blender'), making the tool's function immediately clear. It is distinct from the sibling tools, which concern rendering, simulation, scene editing, or file operations. Even without naming a sibling, there is no ambiguity about what this tool does.

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

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

The description implies usage: an agent would call this when it needs to verify whether Blender is reachable over the socket connection. However, there is no explicit guidance about when to use it versus alternatives, no prerequisite conditions, and no statement about when this check should be performed. The context is inferable but not 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?

No annotations are provided, so the description carries the full burden. It discloses that preview is fast and excludes sky/smoke/water, and that final is high quality, which gives some idea of render output. However, it does not mention what the tool returns (image, file path, sequence), whether it modifies the scene, or how frames/frame_count are used. The Korean sentence is a redundant translation and adds no behavioral detail.

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 short (one English sentence plus a redundant Korean translation) and front-loaded with the main action. It is concise but the Korean line adds no value and the description lacks critical detail, so it is not as effective as it could be. The structure is adequate but the content is incomplete.

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 5 optional parameters, no output schema, and no annotations, the description is severely incomplete. It does not explain what the output is, how frame_count or frames work, what the returned data looks like, or any side effects. An agent would not know how to set parameters beyond quality or what to expect. This is far below the minimum viable context 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 description coverage is 0% – the schema provides only names and defaults, no descriptions. The description explains only the 'quality' parameter in detail. Width, height, frames, and frame_count are not mentioned at all. With five parameters and zero schema descriptions, the description must compensate but does not.

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 and resource: 'Re-render the current scene.' It also enumerates quality levels, which gives some specificity. However, it does not explicitly distinguish itself from siblings like render_video or snapshot, though the mention of 'current scene' and quality presets suggests a still/frame render. Slight ambiguity but mostly clear.

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 explains what each quality option does (preview vs smoke vs final) but provides no guidance on when to use this tool over render_video, snapshot, or set_render. There are no explicit when-to-use, when-not-to-use, or alternative references. The usage context is implied but not stated.

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

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

With no annotations, the description carries the behavioral disclosure burden. It does add useful behavioral context: output format is mp4, it renders the whole scene, and a 72-frame 720p render takes roughly 1–3 minutes. However, it does not disclose blocking behavior, output file location/overwrite behavior, or how frame range parameters interact with 'whole scene'.

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 short and the key statement is front-loaded. However, the Korean sentence largely duplicates the English sentence, so not every line earns its place. The performance benchmark does add value.

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 render tool with 7 optional parameters and no annotations, the description is too thin. It leaves frame-range semantics, quality options, output naming/location, and the relationship to render_preview unspecified. The presence of an output schema covers return values, not invocation guidance.

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

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

Schema description coverage is 0%, so the description must compensate, but it gives no parameter-level explanation. Names like fps, width, and height are somewhat self-explanatory, but quality='smoke', frame_start=0, frame_end=0, and name are ambiguous without additional context.

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 operation: render the whole scene to an mp4 video. It is specific about the verb, resource, and output format. It does not explicitly name or contrast with sibling render_preview, though 'whole scene' offers a partial differentiator.

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

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

There is no guidance about when to use this tool versus render_preview or other alternatives. No prerequisites, no exclusions, and no context about choosing this tool over a preview or snapshot render are provided.

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 present, so the description carries the full burden. It does disclose the effect scope by listing exactly what gets removed and states that originals are restored. But it does not clarify whether the optional target narrows the reset, whether the operation is reversible, or what happens to snapshots or unsaved work.

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 short and front-loaded with the main behavior. The Korean sentence is a redundant expansion of the English one, but it adds a useful enumerated list of affected effects. There is minimal 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?

Given the destructive/reset nature of the tool and the lack of annotations, the description leaves important gaps: target semantics, safety caveats, and interaction with snapshot/restore features. The output schema exists, so return values may be covered, but the description is not complete enough for confident agent 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 single 'target' parameter has 0% schema description coverage, and the description never explains what target accepts or what an empty default means. The parameter name alone hints that it may narrow the reset scope, but the description adds no meaningful semantics beyond the schema.

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

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

The description uses a specific verb ('Remove everything this toolbox created and bring the originals back') and enumerates affected effects (debris, dust, smoke, water, particles, ocean, flag, glue), making it clear this is a reset/undo tool. It distinguishes itself from creation siblings like destroy, explode, and fire, but does not explicitly contrast with the similar sibling 'restore'.

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 reset semantics imply use after destructive effects have been applied, and 'remove everything... bring originals back' gives a clear context for when to call it. However, it does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives such as restore or snapshot.

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 provided, the description carries the full burden of behavioral disclosure. It adds meaningful context by stating that the current scene is auto-saved as 'before_restore' and that the operation is undoable, which informs the agent about safety and reversibility. It does not cover error cases or permissions, but the disclosed traits are valuable.

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 extremely concise, with two short sentences (plus a Korean translation) that front-load the core action and the undo feature. Every sentence earns its place, and there is no redundant or excessive 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 single-parameter tool with an output schema, the description covers the main operation and the undo safety net, but it misses explicit parameter semantics and does not mention potential error conditions (e.g., snapshot not found). The lack of annotations increases the burden, and the parameter ambiguity makes it incomplete.

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 has 0% description coverage, so the description must compensate. However, it only says 'Go back to a snapshot' without explicitly stating that the 'name' parameter refers to the snapshot name. The parameter's meaning is inferable but not explicitly clarified, leaving room for ambiguity. This is 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 clear action 'Go back' and a clear resource 'a snapshot', and explicitly mentions the auto-save undo behavior, which distinguishes it from siblings like 'snapshot' (which creates) and 'list_snapshots' (which lists). The purpose is unambiguous and well-scoped.

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 when to use (to revert to a saved snapshot) but provides no explicit guidance on alternatives, exclusions, or prerequisites. It does not contrast with other tools like 'reset_destroy' or 'clear_caches'. The usage context is implied but not clearly delineated.

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 of behavioral disclosure. It mentions that it saves a .blend file, but does not disclose whether it overwrites existing files, where the file is written, whether it requires a running Blender instance, or any side effects on the scene. This is a significant gap for a save operation.

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 short sentences (English and Korean) that front-load the primary purpose. It is efficient, though the bilingual repetition adds minor redundancy. No unnecessary detail is present.

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?

Given no annotations and 0% schema coverage, the description is incomplete. It omits parameter semantics and behavioral details such as file overwrite behavior and output location. Even with an output schema present, the missing parameter and behavior information leaves the agent under-informed for a save operation.

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

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

The schema defines a single parameter 'name' with no description (0% coverage), and the tool description does not mention this parameter at all. The agent cannot infer that 'name' is likely the filename, as no hint is provided. The description adds zero value beyond the schema.

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

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

The description states a specific verb 'save' and resource 'scene as a .blend file', and adds 'you can open in Blender yourself' which distinguishes it from export_model (which likely produces non-native formats) and snapshot (likely an image). This is clear and well-differentiated.

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 provides no guidance on when to use this tool versus alternatives like export_model, snapshot, or render_video. There is no mention of contexts where saving as .blend is preferable or where other tools are more appropriate.

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 behavioral burden. It clearly indicates a mutating operation ('Set' / '바꾼다'), but it does not disclose side effects, whether existing ground is replaced, how size and z interact with the material, or what the result of an empty call would be.

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 short and front-loaded with the main purpose. The Korean sentence '바닥 재질을 바꾼다' partially repeats the English first sentence, adding minor redundancy, but the overall structure is still 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 simple 3-parameter tool with no output schema and no annotations, this is adequate but not complete. It explains material options and size/z meaning, but leaves gaps around defaults, whether size 0 is meaningful, how z is measured, and what side effects occur when changing the ground.

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

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

Schema description coverage is 0%, so the description must add param meaning. It does: it lists valid material values and explains that size is side length in meters and z is height. This goes well beyond the bare schema, though z's coordinate context is not fully specified.

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 uses a specific verb and resource: 'Set the ground material' with explicit allowed values. This clearly distinguishes the tool from siblings like water, fire, smoke, or wind by targeting the ground specifically.

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 intended use is implied: use this when setting or changing the ground material. However, there is no explicit guidance about when to prefer this tool over alternatives, no prerequisites, and no exclusions.

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 of disclosing behavior. It does mention that HDRI is not fetched from the internet (a useful behavioral constraint) and that procedural sky is only visible in certain render engines. However, it does not disclose what happens to existing lighting when this is called, whether it overwrites the whole scene look, whether it requires a Blender session, or what the return/result looks like. For a tool that changes the scene state, this is a significant gap. No contradiction with annotations since none exist.

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 short and front-loaded: the first sentence states purpose and options. The bilingual Korean text adds a bit of redundancy but also adds the procedural-sky/EEVEE note and HDRI constraint. Not much waste, but it could be more structured (e.g., bulleted parameters). Every sentence generally earns its place, but the mixed language and lack of explicit parameter mapping reduce clarity.

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?

Given 4 parameters, 0% schema coverage, no annotations, and no output schema, the description is incomplete. It provides some context for sky and hdri but leaves preset and sun_strength unexplained, doesn't describe any return value or confirm what the tool does to the scene state, and doesn't mention whether lighting is applied to the current scene or a new one. This is below the minimum viable for a tool with this much undisclosed context.

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

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

Schema description coverage is 0%, so the description must compensate for all four parameters. It explains sky values ('day, sunset, night, overcast or studio; flat colour, procedural sky, or your own HDRI file') and hdri ('path to your own .hdr/.exr file path'). However, it does not explain preset or sun_strength at all, even though they are key parameters. It also doesn't clarify the relationship between sky='flat' and preset, or between preset and sun_strength. This is only partial compensation for a 0%-coverage schema.

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

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

The description states a specific verb and resource: it sets the lighting/sky appearance in a Blender-like scene. It names concrete options (day, sunset, night, overcast, studio; flat colour, procedural sky, or HDRI file) which distinguishes it from sibling tools like camera, set_render, and render_preview. However, it doesn't explicitly name a sibling it is not, so it loses one point for not being fully explicit about differentiation, though the verb 'set' plus resource is clear.

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 provides some guidance: it notes that procedural sky is only visible in EEVEE/Cycles, and that HDRI must be a local path — it won't fetch from the internet. These are conditions for using the parameters, but it doesn't say when to use this tool versus alternatives like set_render or camera. There is no explicit when-to-use or when-not-to-use statement. The added Korean text clarifies constraints but doesn't guide selection among siblings.

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

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

With no annotations, the description carries the behavioral disclosure burden. It gives concrete semantics: gravity 9.81 is Earth, 1.62 is Moon, 0 is weightlessness; increasing substeps/solver_iterations improves accuracy but slows simulation; changing settings rebakes the simulation. This discloses useful non-obvious side effects beyond the raw schema.

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

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

The structure is front-loaded with an English one-line summary followed by compact per-parameter explanations. Each sentence adds meaning, though the Korean-only detail section may reduce accessibility for non-Korean agents.

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 covers most parameter semantics and the important rebake side effect, but it leaves fps unexplained and does not clarify sentinel defaults like -1 or 0. Given seven optional parameters and no annotations, this is adequate but not fully complete.

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

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

Schema description coverage is 0%, so the description must compensate. It explains gravity, gravity_deg, substeps, solver_iterations, and speed with practical values and tradeoffs. However, it omits the fps and rebake parameters entirely, leaving two of seven parameters without semantic guidance.

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 'Global physics: gravity strength and tilt, simulation accuracy, playback speed,' which clearly identifies the resource and scope. It distinguishes set_physics from physics-effect siblings like water, fire, and smoke by labeling it as a global settings tool, though it lacks an explicit verb.

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

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

The description implies usage by listing the configurable physics domains and warning that changes trigger a simulation rebake. However, it does not state when to prefer set_physics over related tools, and there are no explicit exclusions or alternative tool references.

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

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

With no annotations, the description carries the full burden, and it does add real behavioral context: samples higher is 'cleaner and slower,' motion_blur blurs fast objects for a cinematic feel, and transparent_background removes the background. It does not disclose persistence or side effects, but for a settings setter the effect explanations are useful.

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 short and front-loaded in English, but the Korean section partially repeats the same intent and the overall structure is more of a bulleted note than a clear specification. It is efficient, though not polished, and mixes languages without adding structural clarity.

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?

Given 10 parameters, 0% schema coverage, and no annotations, the description should be much more complete. It omits fps and shutter entirely, does not explicitly state that this tool only changes render settings without rendering, and does not clarify how it relates to sibling render tools. The output schema exists but does not compensate for these 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 0%, so the description must compensate. It explains samples, motion_blur, view_transform/look, transparent_background, and resolution/exposure, and gives concrete examples like 'AgX' and 'High Contrast'. However, it completely omits fps and shutter, and width/height are only implied by 'resolution,' leaving some parameters without meaningful guidance.

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 says 'Render quality: samples, motion blur, resolution, exposure and film look,' which identifies the tool's purpose as configuring render settings. It is not a tautology and broadly distinguishes this configuration tool from sibling renderers like render_video and render_preview, but it lacks an explicit verb like 'set' or 'configure' and reads more like a topic summary than an action statement.

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 no guidance on when to call set_render versus render_video, render_preview, set_look, or set_timing. It implies that this tool configures render quality rather than producing output, but it never states that distinction or provides any exclusion criteria.

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 burden of behavioral disclosure. It reveals meaningful behaviors: 0 means 'as is', sectional slow motion excludes particles, and global_slow lengthens the scene while slowing everything. This goes well beyond a generic mutation statement.

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 compact and front-loads the English summary, then provides detailed Korean explanation. There is some bilingual duplication, but each sentence adds behavioral or usage information, 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?

The description covers the core timing behaviors and the important distinction between sectional and global slow motion. However, for a 7-parameter tool with zero schema descriptions, it leaves frame_start/frame_end relationship, slow_factor, and default fps behavior mostly implicit rather than fully specified.

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 has 0% description coverage, so the description must compensate. It explains the semantics of frame range, fps, 0-as-is, slow_from/slow_to behavior, and global_slow scaling with a concrete example (0.25 = 4x slower). It omits slow_factor by name, but the default is present in the schema and is inferable from the slow-motion explanation.

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

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

The description states concrete aspects the tool covers: frame range, fps, and slow motion, which expands the bare name set_timing. It does not explicitly contrast with sibling tools, but no listed sibling covers timing, so the identity is reasonably clear.

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 provides parameter-level usage guidance by distinguishing sectional slow motion (slow_from to slow_to, affecting only rigid bodies, smoke, and water, excluding particles) from global_slow (affecting the entire scene including particles, at the cost of longer duration). It does not explicitly state 'use this instead of X' for sibling tools, but no timing-specific sibling exists.

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 provided, the description carries the full burden of behavioral disclosure. It describes the visual output and notes that arguments match fire, but it does not explain side effects, scene mutation, cleanup behavior, or any operational constraints beyond the effect itself.

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 compact and front-loads the core meaning in English, followed by examples and a useful cross-reference. The Korean sentence partly duplicates the English clause, but the extra parameter note is valuable and the overall size is appropriate.

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 14 parameters, no output schema, and no annotations, this description is incomplete. It gives purpose and examples but leaves parameter semantics, expected effects, and behavioral details to be inferred or looked up elsewhere. An agent would struggle to invoke it correctly without additional information.

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

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

Schema description coverage is 0%, so the description must compensate. The only parameter guidance is 'arguments are same as fire', which is not self-contained and forces the agent to consult another tool's schema. None of the 14 parameters are individually explained.

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 producing 'rising smoke without fire' and gives concrete examples (chimney, smouldering debris, fog column), which distinguishes it from the sibling fire tool. It lacks a strong imperative verb, but the intent is unmistakable.

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

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

The examples and the explicit 'without fire' qualifier give clear usage context for typical smoke-only scenarios. It does not state when not to use alternatives or name sibling tools directly, but the scenarios are specific enough for an agent to select it appropriately.

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 full behavioral disclosure burden. It only says 'save' and 'go back to,' which implies a non-destructive snapshot action, but it does not disclose side effects (e.g., overwriting behavior, uniqueness of names, whether the scene is modified, or what happens when a snapshot name already exists). This leaves critical behavioral aspects undisclosed.

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

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

Two short lines, both earning their place: the English states the core action, the Korean adds usage timing. No fluff, 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 tool with only one parameter and an output schema, the description is mostly adequate bus has gaps. It doesn't explain the name parameter's purpose or any behavioral details, but given the output schema exists, return value documentation is not needed. Overall, adequate 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 0%, so the description must compensate for the single 'name' parameter. It does not mention the parameter at all, giving no guidance on how to name snapshots, whether the name is optional, or what the default '' means. The description adds zero meaning to the schema.

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

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

The description clearly states a specific verb ('save') and resource ('current scene as a snapshot you can go back to'). This distinguishes it from siblings like restore and list_snapshots, making its purpose unambiguous.

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

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

The Korean line explicitly says to call it 'before an operation you might want to undo,' which is clear when-to-use guidance. It doesn't mention alternatives by name, but the context strongly implies it is the right tool for creating restore points.

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 present, so the description carries the full burden. It discloses that the tool drops a water blob and is equivalent to water's drop mode, but it does not explain side effects, whether the action mutates the scene, whether physics simulation is involved, or what happens to the target. This is a minimal action statement without behavioral depth.

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 short and front-loaded with the core purpose, followed by the relationship to water. The bilingual repetition adds some redundancy but is not bloated; it remains an efficient, readable definition.

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 8 optional parameters, no schema descriptions, no annotations, and no output schema, the description leaves too much unspecified for an agent to invoke the tool confidently. It identifies the tool's role but fails to provide enough context about parameter behavior, prerequisites, or outcomes.

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

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

Schema description coverage is 0% and none of the 8 parameters are explained. The description only references water(mode='drop') and does not clarify 'at', 'frames', 'radius', 'target', 'velocity', 'resolution', 'drop_height', or 'preview_frames'. The description does not compensate for the schema's complete lack of parameter documentation.

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 and resource: 'Drop a blob of water on something.' It also clearly differentiates from the sibling tool 'water' by calling itself a shortcut for water(mode='drop'), so an agent can tell them apart immediately.

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

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

The description explicitly says this is a shortcut for water(mode='drop') and that 'water' should be used for more detailed control ('더 세밀한 제어는 water 를 쓴다'). This gives clear routing guidance between the two sibling 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?

With no annotations provided, the description carries the full behavioral burden, and it does so fairly well. It discloses that water fails silently when size is below the simulation grid and reports an error, that drift can be used to verify water movement, and that empty obstacles means all visible meshes except the floor plate are used.

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 long but well organized: a one-sentence summary, then a compact parameter reference with each item on its own line. The English/Korean duplication adds mild redundancy, but the density of useful information justifies the length for a 23-parameter tool.

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 tool is complex with 23 parameters, no annotations, and no output schema, so the description needs to be quite thorough. It covers core behavior well and even mentions drift as a result signal, but it omits seven schema parameters and gives no workflow guidance about frame ranges or domain setup, leaving the agent under-informed for advanced calls.

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

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

Schema description coverage is 0%, so the description must compensate, and it documents 16 of 23 parameters with concrete units, ranges, and defaults. However, several parameters like frames, domain_at, domain_size, smoothing, start_frame, preview_frames, and particle_radius are not described, leaving meaningful gaps for an agent.

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 opening line clearly states a specific action and resource: creating liquid water in forms such as drops, streams, pools, or object-converted meshes. This distinguishes it from sibling tools like fire, smoke, and ocean, which cover different physical effects.

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 explains the tool's own modes and parameters but never contrasts it with alternatives like splash, ocean, or particles. There is no guidance on when to choose water over a sibling tool, so the agent must infer usage from the name and context alone.

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 present, the description carries the full behavioral disclosure burden. It adds meaningful behavior details beyond the schema: direction_deg axis mapping (0=+Y, 90=+X), strength reference levels (1 breeze / 3 normal / 8 gale), and turbulence range (0–3). It does not mention persistence, global vs. selected-object scope, or side effects, but the core behavior is transparent.

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

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

The description is compact and front-loaded with the purpose, followed by parameter semantics. The Korean '바람' slightly duplicates 'wind', and the bilingual phrasing adds a small amount of redundant text, but overall no sentence is wasted and the structure is easy to parse.

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 three-parameter effect tool with defaults and an output schema present, the description covers the essential purpose and all parameter semantics. The main gap is lack of explicit routing guidance relative to sibling effect tools, but the tool is simple enough that this is a minor omission.

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

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

Schema description coverage is 0%, so the description must add all parameter meaning. It does so thoroughly: direction_deg gets an axis coordinate mapping, strength gets concrete wind-level examples, and turbulence gets a numeric range plus the semantic 'shaking'. This is exactly the kind of semantic enrichment a schema cannot provide.

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 begins with a specific verb+resource pairing: 'Wind force that pushes particles, cloth and smoke.' This clearly identifies what the tool does and distinguishes it from siblings like fire, water, or explode, which have different physical effects.

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 when to use the tool—when wind-like force on particles, cloth, or smoke is needed—but it never explicitly states when not to use it or names any alternative tools. Usage context is inferable but not directly guided.

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