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

Annotations already indicate destructiveHint=true, so the mutation risk is known. The description adds that position, rotation, and scale can be toggled independently, which is useful. However, it does not disclose how alignment is computed (e.g., pivot vs. bounding box) or whether existing transforms are overwritten in place.

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 fairly short and front-loaded, but it repeats the same content in Chinese and English, adding redundant length. The core information is present, but the duplication prevents a higher 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?

The parameter schema covers the inputs well, and the description supplies practical use cases. However, for a tool that modifies objects, it lacks detail about alignment reference (pivot, center, bounding box), coordinate space, and whether the operation is reversible beyond the destructiveHint annotation.

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

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

Schema coverage is 100%, with each parameter described including defaults. The description merely restates the existence of position/rotation/scale toggles without adding meaning beyond the schema, so the baseline of 3 applies.

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

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

The description clearly states the verb 'align' and the resource ('several objects to a target'), and gives concrete use cases like placing props and aligning cameras. It does not explicitly differentiate from sibling tools such as cam_align_to_view or light_align_to_object, but the object-target framing is sufficiently distinct.

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 explicit usage context: batch alignment for props, cameras, and aim points. It does not mention alternatives or when not to use the tool, but the use cases are clear enough to guide an agent.

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 concrete behavior beyond annotations: per-frame sampling, writing explicit keyframes, and returning the key count. It aligns with the destructiveHint annotation and adds valuable rationale about engine limitations. It could mention that existing keys may be overwritten, but the destructive hint already covers the risk profile.

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 bilingual description is compact and purposeful, with each sentence contributing either the action, the rationale, or the return value. The English/Chinese repetition is not waste given the dual-language audience, and the key info is front-loaded.

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

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

The description covers the operation, the rationale, and the return value, while the schema handles all parameter defaults. The only notable gap is not mentioning the closely related sibling anim_bake_range, which could leave an agent unsure which bake tool to choose in some scenarios.

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

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

Schema description coverage is 100%, with each parameter (step, objects, endFrame, properties, startFrame) documented in the schema itself. The description adds no parameter-specific semantics beyond the schema, so the baseline of 3 applies.

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

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

The description clearly identifies the specific operation: sampling a procedural/constraint-driven track per frame and writing explicit keyframes, with a clear purpose of preparing for game engine export. It also states the return value (number of keys written). However, it does not explicitly distinguish itself from the sibling tool anim_bake_range, so it doesn't fully earn a 5.

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

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

The description gives strong when-to-use guidance: 'ALWAYS bake before FBX export' because engines cannot evaluate procedural controllers, constraints, or expressions. This is clear and actionable context. It does not mention alternatives or when not to use it, 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?

Annotations already declare destructiveHint=true, so the mutation aspect is covered. The description adds the purpose (export survival) and the return value (number of keys written), which is useful context. However, it does not describe what happens to existing keys or other side effects beyond the annotation. The description does not contradict annotations.

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

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

The description is concise, front-loaded with the core action, and structured in two sentences (in both Chinese and English). It avoids fluff and every sentence earns its place: first states what it does, second gives usage context and return 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 tool with 5 optional parameters, the description covers the main behavior, usage scenario, and return value. The schema already explains all parameters, so the description does not need to repeat them. It lacks explicit mention of default selections or frame ranges, but those are in the schema. Overall, it is sufficiently complete for an agent to call correctly.

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

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

Schema coverage is 100%—every parameter has a description in the input schema. The tool description does not mention any parameter details, so it adds no meaning beyond the schema. With high schema coverage, a baseline score of 3 is appropriate.

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

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

The description states a clear action ('bake') on a specific resource ('entire hierarchy') with explicit scope ('object and all descendants') and outcome ('explicit keys over a frame range'). It also distinguishes itself from the sibling anim_bake by emphasizing the hierarchy scope, so an agent can tell them apart.

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 concrete scenario: 'Bake heavily rigged/constrained characters before export so the animation survives.' This implies the appropriate context and purpose, though it does not explicitly mention alternatives like anim_bake or state when not to use this tool. The guidance is clear but not exhaustive.

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

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

The annotations already flag destructiveHint=true, and the description adds important behavioral detail about what is affected: only the specified tracks, or the three transform tracks by default. This helps the agent understand exactly what will be removed and what will be preserved, beyond the annotation's simple destructive flag.

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, front-loaded, and bilingual without redundancy. Every sentence contributes meaningful information: what is cleared, when properties narrows the scope, and the default track set.

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 and schema together cover the essential call details: target objects, optional property list, default transform tracks, and destructive behavior. It could be more explicit about whether all keyframes on a track are removed or whether undo is supported, but for a simple two-parameter tool this is adequately 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 100%, and the description largely mirrors the schema's parameter explanations. It reinforces the semantics of properties and the default object selection, but adds little beyond what the schema already documents.

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 action: clearing animation keys on an object, with a specific resource (animation tracks). It also defines the fallback scope (position/rotation/scale) when no properties are given, which distinguishes it from generic animation tools like anim_delete_keys or anim_offset_keys.

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 clear conditional rule: if properties is provided, only those tracks are cleared; otherwise position/rotation/scale are cleared. It does not explicitly name alternative sibling tools or state when not to use it, but the context is unambiguous for usage.

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

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

Annotations already mark destructiveHint=true, and the description adds valuable precision about what gets destroyed: either only the supplied frames or every key on the track. This is exactly the kind of destructive scope detail that helps an agent avoid accidentally clearing more animation than intended.

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 bilingual sentences deliver the core action and the destructive conditional up front with no filler. The English version mirrors the Chinese text efficiently, and every sentence earns its place.

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

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

The schema fully documents all three parameters, and the description covers the essential operation-level behavior: partial deletion via frames versus full track deletion. Since there is no output schema and the destructive effect is the key information, nothing critical is missing.

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

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

Schema coverage is 100% and each parameter already has detailed descriptions, so the baseline is 3. The description restates the frames behavior and confirms the property operand, but it does not add new constraints, examples, or semantics beyond what the schema already documents.

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 the exact operation ('Delete keyframes of a property') and adds the key conditional behavior: with frames, only those frames are removed; otherwise the whole track is cleared. This makes it clearly distinguishable from sibling tools like anim_set_keys, anim_get_keys, and anim_clear_animation even without naming them.

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

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

The description gives useful conditional guidance for the frames parameter: pass frames to delete only those frames, or omit frames to clear the entire property track. However, it does not explicitly explain when to use this tool versus related alternatives such as anim_clear_animation or anim_set_keys, so tool-selection guidance is only implied.

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

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

Annotations already indicate destructiveHint=true, so the description does not need to repeat that. However, it does not disclose key behavioral details such as whether the keyframe must already exist, what happens if the handle value conflicts with the tangent type, or whether existing easing is overwritten. These are significant gaps for a mutation tool.

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

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

The description is extremely concise, consisting of two lines (bilingual). It front-loads the action and the key parameters, and every sentence serves a purpose. There is no fluff or redundancy.

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

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

Given the simplicity of the tool and the rich schema (all params documented), the description covers the core purpose. However, it omits important operational details like the requirement of an existing keyframe and the semantics of handle values relative to tangent types. This could lead to incorrect usage.

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

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

Schema description coverage is 100%, so all parameters are already documented. The description adds a general purpose ('to shape easing') but does not elaborate on the interplay between tangent types and handle values, nor does it clarify the meaning of 'handle' beyond what the schema states. It does not compensate for any missing schema details.

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 'set' and a specific resource: the in/out tangent type of a keyframe at a frame, with optional handle values. It is unambiguous about what it does. However, it does not explicitly differentiate itself from sibling animation tools like anim_set_interpolation or anim_set_key, though the focus on tangent types makes it distinct enough.

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. It does not mention that this is specifically for easing, nor does it contrast with anim_set_interpolation or other animation tools. The context signal shows many sibling animation tools, but the description gives no routing information.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the output content (class name and key count) but does not disclose edge-case behavior such as missing controllers, invalid properties, or whether the fallback to selection affects results beyond the schema note.

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 bilingual statement with no filler. The Chinese and English versions each convey the same core information in two clauses, and the key output is stated up front.

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

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

For a simple read-only query tool, the description together with the schema covers what is needed: the property to inspect, the optional object list, and the returned information. Since there is no output schema, naming the two return values helps, but the exact return structure is still left unspecified.

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

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

Schema description coverage is 100%, so the schema already documents both parameters. The description repeats the property examples but adds no new meaning beyond what the input schema provides, so the baseline of 3 applies.

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

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

The description uses a specific verb ('return') and names the exact resource: the controller class name and key count currently used by a given property. This clearly distinguishes it from the sibling anim_set_controller, which performs the opposite write operation.

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

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

The read-only nature and 'currently used' phrasing imply this is a query/inspection tool, but the description never explicitly states when to prefer it over alternatives or mentions the corresponding setter. No exclusion guidance is provided, though the intent is reasonably inferable.

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

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

Annotations already mark this as read-only and non-destructive. The description adds value beyond annotations by specifying that it returns both the frame number and time value, and by explaining the practical risk of skipping this read before keying.

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 core action appears in the first line, followed by a practical caution. The bilingual repetition is slightly redundant, but not enough to hurt 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?

For a zero-parameter, read-only tool, the description is complete: it states what is read, what the output contains, and when to use it. No output schema exists, but the description sufficiently covers the expected return semantics.

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 baseline is 4 and there is nothing for the description to add about parameter meanings. The description correctly implies that no configuration is needed to read the current frame.

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 ('Read') and resource ('current timeline frame and time value'), making the tool's purpose clear. It does not explicitly name or contrast a sibling like anim_goto_frame, but 'current' versus 'goto' is enough to differentiate in context.

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 explicit usage context: check the current frame before keying to avoid placing keys on the wrong frame. It does not mention when not to use it or point to an alternative for moving the time slider, so it falls short of full routing guidance.

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

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

Annotations already mark the operation readOnly/non-destructive; the description adds the concrete read payload (frame, value, tangent types) and pagination behavior via limit/offset. It doesn't mention empty-result or error behavior, but the annotation lowers the burden.

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 bilingual sentences convey the core function exactly, with no filler. The key action and return values are front-loaded before the pagination note.

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 what the tool returns, and the schema/annotations cover parameters and safety. No output schema exists, but the return shape is stated, so the agent has enough to select and invoke it correctly.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters including defaults and the objects fallback to selection. The description only restates pagination and property scope, adding little 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 ('read/读取'), resource ('every keyframe of a property'), and the returned data shape (frame, value, in/out tangent type). It is clear, but it does not explicitly contrast with sibling tools such as anim_get_key_stats or anim_get_controller.

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 use case is implied: when you need all keyframes of a property, this is the tool. However, the description gives no explicit when-to-use guidance or alternatives, leaving the agent to infer selection from the name and sibling context.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context: it operates per object, counts transform-track keyframes, and is paginated, which goes beyond the raw annotations.

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

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

The description is short, front-loaded with the core purpose, and adds a relevant use case. The bilingual duplication costs a small amount of conciseness, but it remains efficient and readable.

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

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

For a simple read-only statistics tool with fully documented parameters, the description covers what it counts, why it is useful, and that it is paginated. With annotations covering safety, nothing essential is missing for an agent to call it correctly.

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

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

Schema description coverage is 100%, so the schema fully documents limit, offset, and objects. The description mentions pagination and object-level counting but does not add meaningful parameter semantics beyond what the schema already provides.

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

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

States a specific verb and resource: count keyframes per object across transform tracks. This clearly identifies what the tool does and distinguishes it from sibling animation tools like anim_get_keys or anim_delete_keys.

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?

Provides a concrete use case: gauging cost before baking a heavy rig. It also notes pagination, but does not explicitly mention alternatives or when not to use the tool, 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?

Annotations already indicate this is not read-only and has a destructive hint. The description adds meaningful detail beyond that: it sets the current time slider position and does not trigger playback. This clarifies the practical effect of the mutation, though 'locates only' could downplay the destructive hint.

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 compact, with the core action and the key behavioral caveat ('does not play') front-loaded. Both English and Chinese versions serve the same clear purpose without unnecessary elaboration.

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 simple single-parameter tool with a clear action, and the description covers the essential behavior. There is no output schema, but none is needed for a navigation/setting operation; minor details like frame range clamping or return value are not critical here.

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

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

Schema coverage is 100% and the parameter description ('Target frame') already explains frame. The tool description reinforces the meaning by linking the frame to the time slider but adds no significant semantic information 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 (jump/set), a clear resource (current time slider/frame), and an explicit boundary: 'does not play.' This distinguishes it from playback and frame-reading siblings like anim_play and anim_get_frame without needing to inspect 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?

The phrase 'Locates only, does not play' gives a clear usage context: use it to position the time slider without starting playback. It provides a relevant exclusion, though it does not name alternative tools such as anim_play or anim_get_frame explicitly.

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

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

Annotations indicate destructiveHint=true, and the description explicitly states the operation is non-destructive in terms of key values, but shifts timing. It mentions all keys move together, implying uniformity, and implies offset can be negative. This adds valuable behavioral context beyond the annotations, clarifying the nature of the destructive 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 sentences (one in Chinese, one in English) with zero redundancy. It front-loads the main action and includes the critical note about all keys moving together. Every word earns its place.

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

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

For a tool that shifts animation keys, the description covers the main operation and parameters. Since there's no output schema, it doesn't explain return values, but that's not critical for a transformation tool. It could mention boundary conditions (e.g., offset beyond frame range) but that's likely handled elsewhere. Adequate for the complexity.

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

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

Schema coverage is 100%, so the schema already describes offset, objects, and property. The description's phrase 'offset frames' adds a tiny bit of context (frames), but it's mostly redundant. Baseline 3 is appropriate since the schema does the heavy lifting.

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

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

The description clearly states the verb 'shift' and the resource 'a whole track in time by offset frames', and explicitly notes that all keys move together. It distinguishes itself from related tools like anim_scale_keys and anim_goto_frame by focusing on time offset.

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 its usage: apply when you need to shift animation keys uniformly in time. It doesn't explicitly exclude alternatives like anim_scale_keys (which scales key timing), but the clarity of 'shift' vs 'scale' makes the choice evident. No explicit when-not guidance is provided, but the context is clear.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=true, so the safety profile is known. The description adds no behavioral context beyond restating the three actions; it does not disclose side effects, what happens on stop, or any state changes beyond playback control.

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

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

The definition is short and front-loaded, with the operation summary before the action mapping. The bilingual repetition and the redundant action= sentence add slight noise, but overall it remains appropriately compact.

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 core actions are covered and the optional frame parameters are documented in the schema. The description is incomplete in that it never specifies viewport versus preview playback, the effect of fromFrame/toFrame during pause/stop, or expected return behavior.

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

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

Schema description coverage is 100%, so the baseline is 3. The description's action= mapping only restates the enum names and does not add meaningful semantics beyond what the schema already provides for action, fromFrame, or toFrame.

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 a specific resource ('the animation') with explicit verbs: play, pause, stop. However, it does not distinguish itself from the closely named sibling anim_play_preview or clarify whether it controls viewport playback, so sibling differentiation is missing.

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 anim_play_preview or anim_goto_frame. The action enum implies playback control, but no conditions, exclusions, or alternative routing 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?

Annotations already declare readOnlyHint=false and destructiveHint=true, covering the write/destructive nature. The description adds useful context that output is a low-quality quick preview, but it doesn't disclose additional traits such as overwrite behavior or resource cost. No contradiction with annotations.

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

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

The description is compact and front-loaded with the core function, then optional parameters, then usage caveat. The bilingual format doubles the length but is justified by the mixed-language audience. No filler or redundant sentences beyond the translation.

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 4 optional parameters fully documented in the schema and destructive behavior flagged in annotations, the description covers purpose, scope, and usage intent. No output schema exists, but for a file-generation tool the output is the written file, so return-value documentation is not essential.

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

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

Schema description coverage is 100%—each parameter already documents defaults and meaning. The description's mention that 'Output path and frame range are optional' simply restates the schema. No additional semantic depth is provided, so it earns the baseline 3.

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: 'Generate a real-time preview animation file (avi / image sequence)'. It also clarifies the tool is for quick checks, not final render, which positions it among animation/render siblings. It doesn't explicitly name an alternative tool, so it stops short of 5.

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

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

The description provides an explicit when-not: 'The preview is for quick checks, not final render.' This tells the agent this is for iteration, not final output. However, it doesn't name a specific alternative like render_animation or render_preview, so while clear, it lacks explicit sibling routing.

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

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

Annotations already mark the tool as destructive, so the description doesn't need to restate that. It adds useful behavioral context: all key times are multiplied, factor<1 speeds up, factor>1 slows down, and pivotFrame serves as the anchor. This makes the mutation concrete beyond the annotations.

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

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

The description is compact and front-loaded, with the action and key semantics in the first sentence. Bilingual duplication is acceptable for accessibility and doesn't add material bulk or irrelevant 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?

The definition covers the operation, the factor behavior, and the pivot anchor, while the input schema fully documents all parameters. For a mutation tool without an output schema, this is sufficient for an agent to call it correctly. The only missing piece is explicit guidance on choosing among sibling animation-timing tools.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds relational meaning beyond the schema by explaining that factor scales time and that pivotFrame acts as the anchor point. It could clarify the exact formula when pivotFrame is nonzero, but the core semantics are clear.

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

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

States a specific verb and resource: 'time-stretch a whole track', with a precise mathematical definition (every key time multiplied by factor around pivotFrame). This clearly distinguishes it from sibling animation-timing tools like anim_offset_keys (shifting) and anim_set_keys (setting key values).

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 description: use this when you want to speed up or slow down an entire track's key times around an anchor. However, there is no explicit guidance about when not to use it or which sibling tool to prefer for shifting vs. scaling keys.

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 explicitly says switching controllers clears existing keys on the track, which adds specific destructive behavior beyond the generic destructiveHint=true annotation. The mutation implied by 'assign/switch' is consistent with readOnlyHint=false, so there is no contradiction.

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: purpose, selection guidance, and destructive warning in that order. The bilingual repetition is redundant for an agent but not excessive, so the structure is only mildly penalized.

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 mutating 3-parameter tool, the description plus fully covered schema cover the main inputs and the key side effect. However, it leaves the controller value mismatch between enum and suggested examples unresolved and does not clarify effects when multiple objects are targeted, so an agent could still call it incorrectly.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds property-type-to-controller mappings, but the suggested values (bezier_position, euler_xyz, tcb_rotation, bezier_float) do not align cleanly with the enum values (Bezier, Euler, TCB, List), and bezier_float appears nowhere in the enum or examples; this added guidance may lead to invalid calls.

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

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

The description opens with a clear verb and resource: assigning a controller to a property, and lists the supported controller types. It is distinguishable from nearby animation tools like anim_set_key or anim_set_interpolation by emphasizing controller assignment and the key-clearing side effect, though it does not explicitly name a sibling 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?

It gives concrete controller recommendations per property kind (bezier_position for position, euler_xyz/tcb_rotation for rotation, bezier_float for scalars), which helps choose parameters. However, it does not state when to prefer this tool over alternatives such as anim_set_interpolation or anim_set_key, or when not to use it; the choice is only implied.

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

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

Annotations already mark this as destructive (destructiveHint=true), and the description adds useful scope context: it applies to every key unless frames is specified. It does not mention reversibility, undo behavior, or side effects, but the annotation lowers the burden.

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 operation and scope. The Chinese/English duplication slightly reduces conciseness, but the content is efficient and every substantive point serves a purpose.

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 complete schema documentation and no output schema, the description plus schema provides enough context for an agent to invoke the tool correctly. It identifies the operation, the possible scope (whole track vs frames), and the optional object selection, though it does not go into deeper animation workflow 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 100%, so the schema already explains type, frames, objects, and property. The description adds no semantic information beyond what the schema provides, so the baseline of 3 is appropriate.

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

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

The description clearly identifies the verb ('set') and resource ('interpolation tangent type') for every key on a track or specified frames. It distinguishes this tool from animation siblings like anim_set_key, anim_set_controller, and anim_ease by naming the exact operation and scope.

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 it: when an agent needs to change key interpolation tangents on a track or specific frames. However, it does not explicitly name alternative tools or state when not to use them, so selection guidance is left to inference.

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

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

Annotations already mark destructiveHint=true, and the description adds valuable behavioral context: rotation is Euler degrees, relative=true adds to current value, and the critical limitation that Euler rotation cannot interpolate past 180° (causing snapping). This goes beyond the annotation and helps the agent anticipate failure modes.

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

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

The description is bilingual and somewhat longer due to repetition, but every sentence carries meaning. The primary action is front-loaded, and the Euler warning is placed at the end where it is easy to notice. No filler or tautological phrasing; the length is justified by the complexity.

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

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

For a tool with 5 parameters, full schema coverage, and destructive annotations, the description covers the key contextual aspects: property types, rotation units, relative semantics, and a critical pitfall. It lacks explicit mention of overwriting behavior or error conditions, but these are partially implied by the destructive annotation and not essential given the schema details.

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

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

Schema coverage is 100%, so the baseline is 3. The description reinforces parameter meaning ('rotation as Euler angles in degrees', 'relative=true adds to current value'), but does not add information beyond what the schema already states. It does not introduce new details about value formats or frame handling 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 clearly states the action: 'Write one keyframe for a property (position / rotation / scale, or any named property) at a given frame.' It is specific about the verb (write) and resource (keyframe on a property). It does not explicitly differentiate from siblings like anim_set_keys, but the singular 'one keyframe' and property focus are sufficiently distinct.

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

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

There is no explicit guidance on when to use this tool versus alternatives such as anim_set_keys or anim_delete_keys. The Euler rotation warning suggests using Quaternion/TCB controllers for large rotations, but that is about controller selection, not tool selection. No when-to-use or when-not-to-use criteria 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?

Annotations already declare readOnlyHint=false and destructiveHint=true, covering the mutation/destructive profile. The description adds efficiency context but does not disclose what happens to existing keyframes on the property, such as whether they are overwritten, merged, or appended.

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?

Bilingual but compact: each version is two sentences with no filler. It front-loads the verb, resource, and key-list format, then adds a concrete walk-cycle usage example that strengthens the purpose without bloating the text.

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

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

With 100% schema coverage and annotations carrying the destructive read/write profile, the description is nearly complete for invocation. The main missing context is an explicit statement of overwrite/replacement semantics for existing keyframes, which destructiveHint only hints at.

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

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

Schema description coverage is 100%, so the schema already fully documents all parameters. The description repeats the keys format ({frame, value}) but adds no new meaning about frame encoding, value types, objects selection, or the relative flag.

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

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

States a specific verb and resource: 'Write many keyframes for one property in a single call.' It explicitly contrasts with the singular sibling anim_set_key, so an agent can immediately distinguish the bulk operation from the per-key version.

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?

Provides clear when-to-use guidance by naming whole walk cycles as the ideal case and pointing out that it is cheaper than repeated anim_set_key calls. It does not explicitly state the inverse case—use anim_set_key for a single keyframe—but the context strongly implies it.

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

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

Annotations declare destructiveHint=true, so the agent knows this operation modifies state. The description adds the behavioral detail that it sets behavior 'outside the animation range', which clarifies the scope of the effect. However, it does not disclose whether this overwrites existing out-of-range settings, whether it applies to all keyframes or only selected ones, or any side effects on the animation. With destructiveHint already present, the description provides some additional context but not rich 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 compact: one sentence in Chinese and one in English, with the core action and enum values front-loaded. The bilingual repetition is somewhat redundant but serves a clear audience purpose. No filler words; every clause carries meaning.

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

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

For a simple setter with 3 parameters and full schema coverage, the description is mostly adequate. However, it lacks context about the relationship to animation controllers: does this affect the whole controller or a specific track? Is 'cycle' a synonym for 'pingpong' or distinct? The destructiveHint annotation covers the mutation risk, but the description doesn't explain what 'out-of-range' means in practical terms (e.g., before first keyframe and after last keyframe). An agent might need more context to invoke it correctly on the right controller.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters. The description adds the meaning of the 'type' enum values (loop/cycle/pingpong/constant/linear) by naming them, but the schema already lists them. The description does not add detail about the 'property' parameter beyond what the schema says (position/rotation/scale or named property), nor about the 'objects' parameter's selection fallback, which the schema already covers. Baseline 3 is appropriate.

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

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

The description clearly states the tool's function: setting a controller's out-of-range behavior, and lists the five possible modes (loop/cycle/pingpong/constant/linear). It is specific about the resource (controller) and the action (set out-of-range behavior). It doesn't explicitly distinguish from sibling animation tools like anim_set_controller or anim_set_interpolation, but the unique 'out-of-range' concept makes it identifiable.

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: it is for configuring out-of-range animation behavior, which is a distinct animation task. However, it does not explicitly state when to use this tool versus alternatives like anim_set_controller or anim_set_interpolation, nor does it mention prerequisites (e.g., the controller must exist, or the property must be animatable). The bilingual format adds clarity but no usage guidance.

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

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

With destructiveHint=true, the description is expected to clarify mutating behavior. 'Array-clone' implies creating copies rather than moving, but it does not state whether originals are preserved, how selection changes, or other side effects. The annotation already warns about destructiveness, so the description is not misleading, but it adds limited 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?

Two short, front-loaded sentences with no filler. The bilingual duplication is redundant but compact and useful, and the mode-specific parameter mapping is organized 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?

The schema covers every parameter and default, so basic calls are feasible. Yet the description leaves ambiguities such as whether count includes the original object, what spacing measures, and how center factors into radial arrays—important details for a destructive operation with no output schema.

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

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

All 11 parameters already have schema descriptions, so the baseline is met. The description adds a valuable mode-to-parameter mapping and names the core parameters for each mode; it omits center from that mapping, but the schema documents it.

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 'Array-clone objects' and immediately scopes the tool to 1D/2D/3D grids or radial distributions. This clearly distinguishes it from sibling duplication/scatter/transform tools even without naming them.

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

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

The description provides useful within-tool guidance by pairing each mode with its relevant parameters ('grid uses count1/2/3 + spacing1/2/3; radial uses count1, axis, radius'). However, it never explicitly says when to prefer this over clone_objects or scatter_objects, and gives no 'do not use' conditions.

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

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

Annotations already mark the operation as readOnlyHint=false and destructiveHint=true. The description adds useful context beyond that: a missing layer is automatically created as a side effect, and 'move' implies objects leave their original layer. It does not discuss undo behavior or effects on objects already in the target layer, but the core mutating side effect is clear.

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 short, front-loaded with the action, and contains no filler. The bilingual phrasing is compact and both versions carry the same essential information without excessive duplication.

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

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

For a simple two-parameter mutation tool with no output schema, the description plus fully documented input schema is largely sufficient. The auto-create behavior and the optional object list are covered. A minor gap is that the description itself does not state the current-selection default, though the schema already does.

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

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

Schema description coverage is 100%: layer is documented as the target layer name, and objects as an optional list defaulting to the current selection. The description adds no major parameter meaning beyond rephrasing the layer concept and the auto-create behavior.

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

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

The description names a specific verb and resource: moving objects into a target layer, with the notable auto-create behavior. It implicitly distinguishes itself from siblings like move_objects_to_new_layer by emphasizing 'target' layer rather than 'new' layer, and from create_layer by combining creation with assignment.

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 alternatives such as move_objects_to_new_layer, create_layer, or set_layer_properties. The auto-create note implies a use case, but no explicit when/when-not conditions or alternatives are given.

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

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

Annotations already mark the tool as destructive, and the description adds useful behavioral detail: the target is converted to an editable spline and receives the other splines. This tells the agent that the target will be mutated into a new editable-spline state, going beyond the annotation alone.

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 action. The bilingual phrasing is redundant for a single-language reader, but each version serves a different audience and the English sentence adds the purpose clause. There is no filler or unnecessary detail.

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

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

For a simple two-parameter mutation tool, the description plus schema covers the target, the objects, the default selection behavior, and the conversion side-effect. The destructive hint handles the risk disclosure. Nothing essential is missing, though it could have stated what happens to the source splines after attach.

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

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

Schema description coverage is 100%, so the schema already documents both 'target' and 'objects' including the behavior of omitting objects to use the current selection. The description adds general context about the attach operation but does not meaningfully enhance the parameter semantics beyond what the schema provides.

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

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

The description clearly identifies the operation: attaching one or more splines into a target spline using Editable Spline attach, with an explicit purpose of combining profiles before extrusion. It is specific enough to distinguish this from sibling spline/modification tools even without an explicit alternative mention.

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 clear context: use this tool when you need to merge multiple splines into a single editable spline contour before extruding. It does not explicitly name alternative tools or list exclusions, but the usage scenario is unambiguous.

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 annotations already signal destructiveHint=true and readOnlyHint=false, so the description is not required to restate mutation risk. It adds context about object prerequisites, which is helpful beyond the structured data. It does not disclose overwrite behavior, file output location, or whether existing maps are replaced, but the destructive hint partially covers that 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 text is short and front-loaded with purpose, but it duplicates the entire content in Chinese and English with a '[English]' marker. The bilingual duplication is not zero-waste for an AI agent, though it remains compact and readable.

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

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

There is no output schema, so the description needs to explain what the tool returns or produces; it only says a map is baked, not the return format or path. It also sits among many bake_* siblings without explaining how it relates to bake_set_output or bake_objects, leaving the agent to infer workflow 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 100%, so the schema already documents size, folder, format, and objects. The description adds no extra meaning for these parameters and does not mention defaults or relationships between them. Per the calibration baseline, this is an adequate score when the schema carries the parameter documentation weight.

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

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

The description opens with a clear, specific action: '把环境光遮蔽（AO）烘焙成一张贴图' and 'Bake ambient occlusion (AO) into a single map.' It clearly names the resource (AO map) and the verb (bake), and the mention of AO differentiates it from other bake_* siblings by map type. However, it does not explicitly contrast itself with bake_texture, bake_normals, or bake_lighting beyond the AO focus.

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 a concrete precondition: objects need a UVW channel and a shell, and it says this is the same requirement as bake_texture. This is useful context for when the tool can be invoked. But it does not explicitly say when to choose bake_ao over sibling baking tools, nor does it give when-not-to-use guidance.

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

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

ReadOnlyHint and destructiveHint already cover the safety profile. The description adds meaningful context by stating the settings are 'global' and enumerating folder, size, format, padding, and template, which clarifies scope and content beyond the annotations.

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

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

The description is compact, front-loaded with the action word, and contains no filler. The bilingual repetition is purposeful and the parenthetical field list is efficient.

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

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

For a zero-parameter read-only getter without an output schema, the description adequately identifies what will be returned. It does not specify value types or default behavior, but that is a minor gap given the tool's simplicity and the readOnly annotation.

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 parameter descriptions are unnecessary. The description still adds value by naming the domains covered by the returned settings, matching the 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?

The description uses a specific verb ('Return') and a specific resource ('current global bake output settings'), and it enumerates the included fields. This clearly identifies the tool as a getter and distinguishes it from sibling setters like bake_set_output.

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 getter semantics imply the tool should be used when you need to read current bake output settings, but there is no explicit when-to-use guidance or mention of alternatives such as bake_set_output. This is adequate but relies on inference.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the description does not need to repeat that. It adds the UVW channel requirement, which is a behavioral prerequisite, but does not disclose other side effects (e.g., file overwriting, render engine requirements, or performance implications). The description adds some context beyond annotations but is not rich; a 3 reflects this minimal extra value.

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

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

The description is concise, with two sentences per language, and front-loads the core action and purpose. It is efficient, though the bilingual duplication doubles the length without adding new information. This is a minor inefficiency but not a significant distraction; a 4 fits the appropriately sized and front-loaded criteria.

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 straightforward baking tool with all-optional parameters and no output schema, the description covers the essential context: what it does, the purpose, and the key prerequisite (UVW channel). It does not mention potential pitfalls like render engine requirements or overwriting behavior, but given the annotations already flag destructiveness, these are not critical gaps. The description is adequate for an agent to invoke 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 input schema provides 100% coverage with descriptions for all four parameters (size, folder, format, objects). The description does not add any additional parameter-specific guidance beyond what the schema already states. Since the schema handles parameter documentation, the baseline of 3 is appropriate; the description contributes nothing further here.

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 action ('bake lighting / a complete map'), the target resource ('LightingMap or CompleteMap'), and the purpose ('for static lighting'). It also distinguishes itself from sibling tools like bake_ao and bake_normals by specifying the lighting map type. The prerequisite (UVW channel) adds specificity. This is a clear, non-tautological 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 provides clear context: it is for static lighting and requires a UVW channel, which tells the agent when it is applicable. It does not explicitly name alternative tools or state when not to use it, but the specific purpose and prerequisite make the use case evident. It stops short of a 5 because it lacks explicit exclusions or alternative routing.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the write/destructive nature is covered. The description adds valuable context beyond that: the requirement of a UVW channel and that the high/low relationship depends on RTT projection setup. This helps the agent anticipate prerequisites and potential failure points, going beyond what annotations provide.

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

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

The description is concise, consisting of two sentences, and front-loads the core purpose. It avoids fluff and provides the essential prerequisites in a structured bilingual format. Every sentence contributes to understanding the tool's function and constraints.

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 moderately complex, but the description covers the key prerequisites (UVW channel, RTT projection) and the action. It does not mention the output file behavior (e.g., whether the map is assigned to the material or just written to disk) or potential side effects beyond the destructiveHint annotation. However, given the schema covers parameters and annotations cover safety, it is reasonably complete for an agent to invoke it correctly.

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

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

The schema covers all four parameters with descriptions (100% coverage), so the baseline is 3. The description does not add any additional parameter-specific semantics (e.g., default behavior of 'objects' falling back to selection) beyond what the schema already states, so it does not exceed the baseline.

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

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

The description clearly states the action (bake) and the resource (a normal map) and specifies the source (high-poly cage) and target (low-poly shell). It distinguishes itself from sibling bake tools by explicitly naming 'NormalMap' and mentioning the RTT projection relationship, 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?

It provides clear prerequisites: requires a UVW channel and the high/low relationship is governed by RTT projection setup. This tells the agent when the tool is applicable. However, it does not explicitly mention alternatives (e.g., bake_ao, bake_lighting) or state when not to use this tool, so it misses explicit exclusion guidance.

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

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

Annotations include destructiveHint: true, and the description does not contradict that, nor does it elaborate on the destructive aspects. It does disclose that returns per-map write results and missing files appear in failures/written, which is useful beyond annotations. However, it doesn't detail what is destructive (overwriting files?) or any side 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, with key information up front: 'low level bake', required elements, and return behavior. Bilingual but not redundant. Each sentence adds value, though it could be shorter by dropping the bilingual repetition, but it's not bloated.

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 complexity (6 params, no output schema), the description covers the essential points but lacks detail on object naming conventions, template placeholders (%s, %e), and potential failure modes beyond listing them. It doesn't explain how missing files are reported or the impact of destructiveHint. With sibling bake tools present, more context on differences would help.

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

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

Schema description coverage is 100%, so all parameters are described in the schema. The description adds the key point that elements is required and gives an example, which is helpful but not extensive. It doesn't add extra meaning beyond schema for size, folder, format, objects, template.

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 it is a low-level bake operation on a list of objects with an explicit element list, and mentions the required parameter. It distinguishes itself from higher-level bake tools like bake_texture, bake_ao, bake_normals, and bake_lighting by being low-level, though it doesn't explicitly name them.

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

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

It implies this is the low-level alternative but doesn't explicitly state when to use this vs. the other bake_* tools. It mentions 'low level bake' as a label, which gives context but no exclusions or alternative names.

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

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

Annotations already flag readOnlyHint=false and destructiveHint=true, and the description's 'Set' aligns with mutation. It adds useful context by specifying 'global' scope and explaining the template placeholders (%s=object name, %e=element name). However, it does not describe overwrite semantics or side effects on existing bake settings; annotations carry some of that burden.

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 compact sentences, one Chinese and one English, with the action and resource front-loaded before the parameter list. Every phrase contributes; there is no filler or redundant restatement of the tool name.

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 setter with five optional parameters, full schema coverage, and no output schema, the description plus annotations are largely sufficient. It could explicitly state that these settings persist and apply to subsequent bake calls, but the term 'global' and the sibling context make that inferable.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value beyond the schema by explicitly defining the filename template placeholders (%s=object name, %e=element name), which an agent needs to construct correct templates. This extra semantic detail justifies a 4.

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

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

The description opens with a concrete verb ('Set') and a specific resource ('global bake output parameters'), and enumerates the five configurable aspects: folder, map size, format, filename padding, and template. The word 'bake' clearly distinguishes it from render output setters like render_set_output, and it pairs naturally with bake_get_settings.

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

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

The description clearly signals that this is the configuration step for bake output: it sets global parameters before bake operations. It does not explicitly name alternatives or state when not to use it, but the intended context is unambiguous and no exclusion is needed.

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

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

Annotations already signal destructiveHint=true, and the description adds the UVW prerequisite and the smeared-map failure mode, which is useful. However, it does not disclose what the destructive behavior actually involves, such as overwriting existing files in the target folder or changing the scene's render output settings.

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

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

The description is front-loaded with purpose and organized into Chinese and English halves, which is likely intentional for this Max tool. It is compact, but the English section repeats the Chinese content and phrases like 'the single most used tool' add little functional 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 destructive batch tool with six optional parameters and no output schema, the description covers the main preconditions (UVs, output setup) and the result (baked maps in a target folder). It could mention overwrite behavior and return status, but the annotations and schema carry enough of that burden.

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

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

Schema coverage is 100%, with all six parameters already described bilingually in the input schema. The description adds little beyond the schema, only reinforcing the output-folder concept and the 'current material maps' idea, so the baseline of 3 is appropriate.

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

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

States the exact operation: bake selected objects' current material maps into a target folder, with the pipeline goal of getting a Max asset into a game engine with its look intact. It does not explicitly contrast with sibling tools like bake_objects, bake_normals, or bake_ao, so it stops short of full differentiation.

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

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

Provides concrete usage context: objects must have a UVW channel and a clean shell/offset, otherwise the result is overlapping UVs and a smeared map. It also instructs the agent to set the output first with bake_set_output. It lacks an explicit when-not-to-use comparison with the other bake_* siblings, so it is not 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?

The description describes a stateful operation that modifies the undo stack ('Everything you do until end_undo collapses into a single undo step'), yet the annotations declare readOnlyHint=true, which typically indicates no state changes. This is a direct contradiction, undermining the agent's trust in the tool's side 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 two sentences, front-loaded with the core action, and includes a concrete example. No unnecessary words, despite the bilingual duplication.

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 one optional parameter and no output schema, the description covers the operation's purpose, scope, and the pairing with end_undo. It could additionally mention cancel_undo or the necessity of closing the transaction, but the current detail is largely sufficient.

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 includes a full description for the only parameter 'label' (coverage 100%). The description adds no extra semantics about this parameter, so the baseline of 3 applies.

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

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

The description states a specific verb and resource: 'Open an undo transaction spanning several MCP calls.' It clearly distinguishes the tool from siblings like undo_last and end_undo by describing its role as a transaction opener, not an undo operation itself.

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

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

The description gives an explicit use case: 'ideal for multi-step tasks such as building and rigging a character.' It also references end_undo as the necessary closing pair, implying when to use it. However, it does not explicitly mention alternatives like cancel_undo or warn against using it for single operations.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false. The description adds valuable behavioral context beyond that: the order of operations (subtract = A minus all others) and the failure condition (broken faces fail). This is meaningful supplementary information that helps the agent anticipate outcomes.

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 bilingual sentences with zero waste. The action, operands, and the critical warning are front-loaded. The bold emphasis on the watertight requirement draws attention to the key constraint. Every sentence earns its place.

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

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

For a destructive boolean tool with no output schema, the description covers the essential operational details: operand order, operation semantics, and failure condition. It doesn't explicitly state the outcome on the original objects (e.g., A is modified), but the destructiveHint annotation implies that. Overall it is reasonably complete, with minor gaps around return behavior.

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

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

Schema coverage is 100%, so the schema already documents both parameters. The description adds semantic depth by explaining the subtract operation (A minus all others) and the requirement for watertight meshes, which are not fully covered in the schema. This compensates beyond the baseline of 3.

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 (boolean operation), resource (selected objects), and scope (union/subtract/intersect/merge). It clearly explains the first object is A and others apply to it, distinguishing from sibling tools like attach_objects (which merges without boolean logic) and proboolean (a specific Max tool). The purpose is unambiguous.

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

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

Provides clear context for use: operates on two or more selected objects, and requires watertight meshes. However, it does not explicitly contrast with alternatives like proboolean or attach_objects, nor state when to choose this tool over them. The 'when to use' is implied by the operation type, but no exclusions are given.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only nature is covered. The description adds useful behavioral context by stating that the command list reflects what is 'actually registered on the 3ds Max side' and that results are 'grouped by prefix,' which implies a dynamic, version-specific inventory.

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, front-loads the primary action, and immediately follows with the key usage instruction in bold. The bilingual repetition is justified for a multilingual agent context and does not add unnecessary detail.

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

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

With zero parameters and no output schema, the description only needs to convey what the tool does, how output is organized, and when to use it. All three are addressed clearly, making the definition complete and self-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?

The tool has zero parameters, so the input schema is empty and there is nothing for the description to explain. The 0-parameter baseline of 4 applies, and the description does not introduce any confusing or conflicting parameter expectations.

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 specific verbs ('List every command actually registered... grouped by prefix') and a clear resource, making it obvious this is an introspection tool for the available command set. It distinguishes itself from sibling bridge_* tools by focusing on command registration rather than connection status or ping.

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 tells the agent when to call this tool: 'Call it first whenever you are unsure whether a tool exists on this Max version.' This is a clear, actionable precedence rule that prevents guessing and directly supports tool 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?

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds useful context beyond that: it is lightweight, returns a timestamp, and has zero scene side effects. No contradictions with annotations.

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

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

The core message is front-loaded in two short sentences covering purpose, usage, and non-mutation. The bilingual repetition is slightly redundant but remains compact and 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 zero-parameter heartbeat tool, the description is complete: it states what the tool returns, why to call it, and that it is side-effect-free. The absence of an output schema is mitigated by the explicit note that a timestamp is returned.

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 is complete with no properties. Per the 0-parameter baseline, the description has no parameter documentation burden and adds no unnecessary parameter detail.

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

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

The description states a specific verb-resource pair: a 'lightweight heartbeat' that returns the Max internal timestamp. It clearly identifies the tool's purpose of confirming bridge liveness and explicitly notes it never modifies the scene, distinguishing it from mutation-heavy siblings.

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

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

The description explicitly says when to use it: 'Use it to confirm the bridge is alive.' It also clarifies that it never touches the scene, implying safe health-check usage. It does not name alternative sibling tools like bridge_status, but the usage context is unambiguous.

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 says 'Restart the bridge,' which is a state-changing operation, but the annotations declare readOnlyHint=true. This directly contradicts the annotation and could mislead an agent relying on read-only semantics. The added detail about keeping the current port is useful, but the contradiction dominates this dimension.

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 action, default behavior, and use case each appear in short, direct sentences. The bilingual format does not introduce unnecessary verbosity and every sentence earns its place.

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

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

For a simple tool with one optional parameter and no output schema, the description covers the action, default port behavior, and when to invoke it. It does not explain return values or post-restart behavior, but these are not critical for this operation; the main completeness issue is the annotation contradiction already flagged.

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

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

The schema already describes the single optional port parameter with 100% coverage, including the fact that omitting it keeps the current port. The description restates that behavior but does not add new parameter semantics beyond what the schema provides. With high schema coverage, baseline 3 is appropriate.

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

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

The description states a specific action ('Restart the bridge') on a specific resource, and adds the meaningful scope detail that it keeps the current port by default. It is also clearly distinguishable from sibling bridge tools like bridge_status, bridge_ping, and bridge_stop because 'restart' conveys stop-and-start rather than status or connection checks.

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 an explicit trigger condition: use it when an AI client lost the connection and cannot recover. This is clear contextual guidance, but it does not mention alternatives or conditions where this tool should not be used, so it stops short of full routing guidance.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false; the description adds what the self-test covers and that it returns per-check results. It does not state whether temporary objects from the object-creation check are cleaned up, but the read-only annotation covers the safety profile and there is no contradiction.

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

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

Two compact bilingual paragraphs with the core function first, then the usage trigger. No filler; the repetition between Chinese and English is small and does not hurt readability 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 one-optional-param, read-only diagnostic tool, the description covers the checks performed, the return concept (per-check results), and the recommended use case. With no output schema, it could specify the result format more concretely, but the agent still has enough to invoke and interpret the tool.

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

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

Schema description coverage is 100%: the single optional echoText parameter is already documented as verifying non-ASCII/Chinese encoding. The description mentions Chinese round trip in general but adds no parameter-level information beyond the schema, so baseline 3 applies.

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

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

States a specific verb+resource ('Run a full in-Max self test') and enumerates the exact subsystems checked (JSON encode/decode, Chinese round trip, object creation, undo stack, TCP listener). This distinguishes it from status/ping/capability siblings even without naming them.

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

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

Explicitly gives the trigger: 'Run it whenever a tool fails oddly' and explains the diagnostic payoff (tell environment problem from bad argument). It lacks an explicit 'do not use bridge_status/bridge_ping for this' exclusion, but the context is clear.

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

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

Annotations declare readOnlyHint=true and destructiveHint=false, and the description is fully consistent (a read-only status report). The description adds value beyond the annotations by specifying the exact fields reported, which is useful behavioral context. No contradiction exists. It doesn't document error/edge behavior when the bridge is down, but for a status tool this is adequate.

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

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

The description is well-structured: front-loaded field list followed by the 'call first' directive. The bilingual duplication (Chinese + English) adds length, but this appears to be a deliberate convention for the toolset, and both sentences earn their place. No wasted filler.

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

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

For a simple zero-parameter status tool, the description covers purpose, reported fields, and usage timing. No output schema exists, but the enumerated field list partially compensates. It would be marginally improved by noting behavior when the bridge is unreachable, but nothing critical is missing for correct invocation.

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

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

The tool has 0 parameters with 100% schema coverage (empty properties object). Per the baseline for zero-parameter tools, the description need not explain parameter syntax. It correctly focuses on what the tool reports rather than inputs.

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 (报告/Report) and resource (live bridge state) and enumerates exactly which data points are returned: listening, port, connected clients, command count, Max version, current scene, object and selection counts. It is clearly distinguished from siblings like bridge_ping, bridge_selftest, and bridge_capabilities by listing its concrete fields.

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?

Provides explicit when-to-use guidance: 'Call this first to confirm the connection is healthy' before starting any operation. This gives clear context for the agent. It does not explicitly name alternatives or state when not to use it, but the 'call first' directive is strong 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?

The description transparently discloses a major side effect: 'Every MCP tool will fail afterwards until mcpBridgeStart() is run again.' However, the annotations declare readOnlyHint=true, which implies the tool has no state-changing side effects. This contradicts the description's clear statement that stopping the bridge alters the availability of all other tools, so the score is 1 due to the contradiction.

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

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

The description is concise and front-loaded with the core action in both Chinese and English. It uses only two sentences to convey the action and the key consequence. The bilingual duplication is slightly redundant but not bloated, and all information is essential.

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 actionainer, the result (release port), and the critical consequence (all tools fail until restart). It does not describe the return value, but for a simple stop operation this is a minor omission. Given the absence of output schema and parameters, the description is sufficiently complete for an agent to understand the tool's impact.

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 parametersate. With 0 parameters, the baseline is 4, and the description correctly does not waste space on parameter details. The schema already covers the empty parameter set completely.

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: 'Stop the bridge and release the port.' It names the specific resource (bridge) and the effect (releasing the port). The additional consequence of all MCP tools failing clearly distinguishes this from sibling tools like bridge_status, bridge_restart, and bridge_ping.

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 it (to intentionally stop the bridge) and mentions the recovery path via mcpBridgeStart(). However, it does not explicitly compare it with alternatives like bridge_restart or state when one would NOT want to use it. The guidance is present but not fully developed.

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

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

Annotations already mark the operation as destructive, and the description adds concrete mutation details: the camera's position and orientation change, and a target camera's target moves as well. This goes beyond the annotation by specifying exactly what gets modified.

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 behavior, followed by the important target-camera nuance. The bilingual duplication is acceptable and does not add meaningful 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?

With one fully documented parameter, no output schema, and annotations covering destructiveness, the description provides enough detail to call the tool correctly. It covers the main effect and the target-camera special case, though broader usage and prerequisite context are absent.

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

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

The input schema already fully describes the single 'camera' parameter as the camera name. The description adds no additional parameter-level meaning, so the baseline 3 applies.

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

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

The description uses a specific verb ('align'), resource ('camera'), and target ('current view'), and clarifies what happens to the camera's position, orientation, and target. It is unambiguous, though it does not explicitly differentiate itself from sibling tools like cam_look_through or cam_set_viewport.

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 use this tool versus alternatives, and names no related tools or exclusions. An agent must infer intended usage from the name and basic effect, with no help navigating the large sibling set.

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 annotations already signal a mutating/destructive operation, and the description is consistent with that. It adds the free/target behavioral variants and the ability to set position, target, and fov, but mostly restates schema information rather than explaining side effects or creation 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 two short bilingual sentences, opens with a clear verb-object pair, and contains no filler. It is well-structured, scannable, and appropriately sized for a simple creation 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 schema and annotations cover the parameters and mutation safety well, but the description does not distinguish cam_create from cam_create_physical or describe what happens after creation. It is sufficient for basic use but incomplete for confident tool selection among camera siblings.

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

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

Schema coverage is 100%, so the baseline is 3. The description merely echoes 'position, target and fov' without adding semantics beyond the schema—such as which parameters apply to which camera type or coordinate expectations.

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 ('Create a camera') and names the supported subtypes 'free' and 'target', making the core purpose clear. It does not explicitly differentiate itself from the sibling cam_create_physical, so it stops short of a 5.

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

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

The description implies it should be used when creating a standard free or target camera, but it provides no explicit when-to-use versus alternatives or exclusions. Given the close sibling cam_create_physical, the absence of routing guidance is a noticeable gap.

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

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

Annotations already communicate readOnlyHint=false and destructiveHint=true, and the description's 'Create' behavior is consistent with that. The description adds the list of adjustable camera attributes, but does not disclose side effects, defaults, or whether a camera object is added to the scene. No annotation contradiction.

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 action and resource, followed by a concise parameter summary. The bilingual repetition is reasonable for the audience, and there is no filler, though the parameter list is somewhat redundant with the schema.

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

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

For a creation tool with no output schema and a destructive annotation, the description gives enough to understand the basic operation. However, it omits usage context relative to cam_create, default behaviors, and any prerequisites or side effects, leaving moderate gaps for an agent deciding how to invoke it correctly.

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

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

The input schema has 100% description coverage for all 9 parameters, so the schema already documents each field. The description provides a high-level summary of parameter categories but adds no additional meaning, constraints, or format details beyond the schema.

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

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

States a specific verb 'Create' plus the resource 'Physical Camera' and enumerates the main configurable settings (focal length, f-stop, shutter, ISO, DoF, FOV). This clearly distinguishes it from camera query/set tools, though it does not explicitly differentiate from the sibling cam_create.

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

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

No guidance on when to use this tool versus alternatives such as cam_create, cam_set, or other camera creation tools. The description implies usage through the name but provides no exclusion conditions or context for choosing it.

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

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

Annotations already flag destructiveHint=true, and the description strengthens this by specifying that the deletion is not recoverable and should be used with care. This adds permanence context beyond the generic destructive flag, though it does not describe effects on linked scene objects or missing-name 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 compact, front-loads the action, and includes a clear warning. The bilingual duplication is purposeful for the likely user base and adds no unnecessary detail.

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

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

For a single-parameter destructive operation with a destructiveHint annotation and no output schema, the warning plus the parameter schema is nearly complete. It could mention error behavior for unknown camera names, but that is a minor gap.

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

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

Schema description coverage is 100%; the only parameter 'camera' already has an explicit name and description. The tool description adds no additional parameter guidance, so the schema carries the semantic load.

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

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

The description states a precise action ('Delete a camera') on a specific resource. It clearly distinguishes itself from sibling camera tools like cam_create, cam_get, cam_set, cam_list, and cam_set_viewport by identifying the deletion operation.

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

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

The intended use is implied by the imperative 'Delete a camera,' but no explicit when-to-use or when-not-to-use guidance is provided. The description does not mention alternatives or exclusions, though no direct deletion 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds value by specifying exactly which camera properties are returned, which is useful given there is no output schema. It does not mention error behavior for nonexistent cameras, but for a simple read-only getter this is a minor 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 compact and front-loaded, presenting the core purpose in the first clause and then listing the specific returned attributes. The bilingual repetition is acceptable and does not add unnecessary bulk; every sentence serves to clarify the tool's behavior.

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 one fully documented parameter, no output schema, and a read-only annotation, the description is largely sufficient: it names the parameter and the returned fields. It could be slightly more complete by explicitly noting error behavior or output format, but these are not critical for selecting and invoking this simple getter.

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

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

The input schema already provides 100% coverage for the single 'camera' parameter with the description 'Camera name.' The tool description does not add further semantic detail about the parameter, so it does not exceed the baseline established by the schema coverage.

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

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

The description clearly states a specific verb ('Read'), a resource ('a camera'), and enumerates the exact details returned: position, field of view, focal length, and active viewport status. This distinguishes it from sibling tools like cam_list, cam_set, and cam_create by focusing on read-only retrieval of one camera's properties.

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

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

The description implies this tool is for retrieving details of a specific camera, but it does not explicitly state when to prefer it over alternatives such as cam_list for listing cameras or cam_set for modifying them. There is no explicit when-to-use or when-not-to-use guidance, leaving the usage context inferred rather than 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?

Annotations already mark this as read-only and non-destructive, and the description adds useful behavioral context: results are paginated and include specific fields. It does not contradict the annotations.

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

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

The description is compact and front-loaded: it states the purpose, the exact data returned, and the pagination behavior in two short bilingual lines. No filler or irrelevant 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?

For a simple list operation with annotated read-only safety and fully documented pagination parameters, the description is nearly complete. It could optionally specify the exact output shape or empty-result behavior, but none of that is critical for calling the tool.

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

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

Schema coverage is 100%, with limit and offset already documented including defaults. The description only reinforces pagination without adding new parameter-level semantics, so the schema carries the weight.

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 and resource: 'List every camera in the scene', and names the returned fields (name, class, position). It clearly separates this from sibling camera tools like cam_get or cam_set by emphasizing enumeration of all cameras.

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

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

The description clearly establishes the context: use this tool when you need every camera in the scene, not a single camera's details. It does not explicitly name alternatives or exclusions, but the scope is unambiguous.

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

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

Annotations indicate readOnlyHint=false and destructiveHint=true. The description does not explain why the operation is marked destructive, nor does it disclose side effects such as whether the viewport change is persistent, reversible, or affects only the active view. It adds no behavioral context beyond the annotations themselves.

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 bilingual but concise, containing only two short sentences that front-load the action. There is no unnecessary elaboration or repetition, making it easy to scan and understand.

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 one parameter and no output schema, the description is adequate. It defines the action and the parameter, and the scope (active viewport) is explicit. Minor details like error conditions or prerequisites (e.g., an existing camera) are not mentioned but are not critical for a basic viewport 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 provides a full description for the single 'camera' parameter ('相机名称。 | Camera name.'), covering 100% of parameter semantics. The tool description only references 'this camera' without adding further meaning, so the baseline 3 applies.

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

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

The description clearly states the action: 'Make the active viewport look through this camera.' It specifies a verb, resource (active viewport), and effect (look through the camera). It is distinguishable from siblings like cam_align_to_view or cam_set_viewport by focusing on the viewport perspective rather than camera alignment or general viewport settings.

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. Sibling tools such as cam_set_viewport and cam_align_to_view exist but are not mentioned, nor are any conditions for exclusion. The purpose is clear but the selection context is left to the agent.

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

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

Annotations already convey readOnlyHint=false and destructiveHint=true, so the description's 'modify' adds no new behavioral information. It does not disclose whether only supplied properties are overwritten, whether the camera must already exist, or what happens on failure. No contradiction with annotations.

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

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

One compact bilingual sentence front-loads the verb and resource, followed by a complete list of the modifiable properties. There is no filler or unnecessary explanation.

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 the schema documenting all 10 parameters and annotations marking the operation as non-read-only/destructive, the description plus schema is largely sufficient. The main missing context is behavior when the named camera does not exist and an explicit pointer to cam_set_viewport for viewport changes.

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

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

Schema description coverage is 100% and every parameter has its own bilingual description, so the baseline is 3. The description simply repeats the same field names and does not add semantics such as coordinate order, units beyond the schema, or relationships among fields.

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

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

The description names a specific verb-resource pair ('Modify a camera') and enumerates exactly which attributes change (name, position, target, FOV, focal length, f-stop, shutter, ISO, DOF). This clearly separates it from read/lookup tools like cam_get, though it does not explicitly call out the viewport-setting sibling cam_set_viewport.

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: whenever an agent needs to change camera properties, this is the tool. But there is no explicit when-to-use guidance, no mention of alternatives, and no exclusion such as 'for viewport changes, use cam_set_viewport'.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=true, so the mutating nature is disclosed. The description adds context by equating the action to entering the camera's view, which clarifies the side effect on the user's viewpoint. This goes beyond the annotations, providing useful behavioral detail without repetition.

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 concise sentences (one bilingual), directly stating the action and its equivalence. No unnecessary detail, front-loaded with the core purpose. Every word earns its place.

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

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

For a simple two-parameter tool with full schema coverage and no output schema, the description is complete. It explains what the tool does, the optional viewport behavior, and the expected outcome. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema coverage is 100%, with both parameters (camera name and viewport index) already documented in the input schema. The description reiterates the viewport index meaning but adds no new semantics beyond the schema. Baseline 3 is appropriate when the schema handles 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 clearly states the action: setting a camera as the active viewport, with an optional viewport index. It also provides an equivalent metaphor ('entering that camera's view'), which makes the purpose unmistakable and distinguishes it from sibling camera tools like cam_look_through or viewport_set_view.

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 core behavior and the optional viewport parameter, giving enough context for when to use it. It doesn't explicitly mention alternatives or exclusion criteria, but the purpose is clear enough that an agent can infer when to select this tool over similar ones. No misleading guidance.

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

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

The description states that the tool rolls back all changes, which is a mutating/destructive behavior. This directly contradicts the annotations readOnlyHint=true and destructiveHint=false. Annotation Contradiction.

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 compact sentences in Chinese and English with no filler. The core action and effect are front-loaded, and every word earns its place.

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

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

For a zero-parameter paired control tool, the description names its counterpart (begin_undo) and the effect (rollback), which is sufficient for an agent to understand the call. The only weakness is that the annotations conflict with the described behavior, which harms overall completeness.

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 properties, so there are no parameter semantics to document. The baseline of 4 applies because the description cannot add meaning where no parameters exist.

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 ('cancel') and resource ('the transaction opened by begin_undo'), and explicitly states the effect: rolling back everything inside it. This clearly distinguishes it from sibling undo/redo/transaction tools.

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

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

The description clearly ties this tool to begin_undo, giving the relevant context: it operates on the transaction that begin_undo opened. It does not explicitly name alternatives or exclusions, but the pairing is clear enough for a zero-parameter tool.

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 adds meaningful behavioral context beyond the annotations by clarifying that copy is independent, instance is linked, and reference is a reference, and that count>1 arranges clones by offset. The destructiveHint annotation already signals mutation, and the description does not contradict any annotation.

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

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

The description is short, front-loaded with the core operation, and uses compact bilingual phrasing. The duplication between Chinese and English is slightly redundant for an AI agent, but it does not significantly bloat the text.

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

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

The definition covers the main behavior, clone modes, and offset spacing, and the schema fills in parameter defaults and object selection defaults. There is no output schema, but for a scene-mutation tool with clear annotations and parameter documentation, the description is adequately 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?

The schema already documents all parameters at 100% coverage, providing a baseline of 3. The description goes beyond the schema by giving semantic meaning to cloneType (independent/linked/reference) and explaining the relationship between count and offset (spacing behavior).

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

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

The description clearly states the tool clones objects and defines the three clone modes (copy, instance, reference) plus offset spacing when count > 1. This is a specific verb+resource description with meaningful semantics, though it does not explicitly distinguish clone_objects from related siblings like array_objects or scatter_objects.

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 explaining the clone-type semantics and spacing behavior, so an agent can infer when to use it for copies/instances/references. However, it provides no explicit guidance about when to prefer this tool over alternatives such as array_objects or scatter_objects, and no exclusions or prerequisites are stated.

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

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

Annotations already declare destructiveHint=true, so the agent knows this is a destructive operation. The description adds the notion of 're-collapse,' which clarifies the specific behavior, but it does not disclose what happens to objects inside the group or any side effects beyond collapsing. It adds a little context but relies on the annotation for the destructive nature.

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: two short sentences, with the English version front-loaded and no redundant wording. Every word adds 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 tool with one optional parameter and no output schema, the description is complete. The destructive hint is in annotations, the parameter is fully documented in the schema, and the operation is clearly described. Nothing essential is missing.

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

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

The schema covers 100% of the parameter, including its optionality and default to the selection. The description adds no additional parameter information, but given high schema coverage, a baseline of 3 is appropriate. No extra semantics are provided.

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 action: closing a previously opened group (re-collapsing it). It uses a specific verb and resource, and the term 're-collapse' distinguishes it from sibling tools like ungroup_objects or group_objects. The purpose is unambiguous.

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

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

The description implies the tool is for groups that were previously opened, but it does not explicitly state when to use it versus alternatives like ungroup_objects or open_group. There is no explicit when-not-to-use guidance, but the context is inferable from the name and description.

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

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

While the annotations already set destructiveHint=true, the description adds critical context by explicitly stating that 'This permanently destroys the editability of every modifier.' This goes beyond the bare hint, explaining exactly what is lost (modifier editability) and reinforcing the irreversibility. The description also clarifies the baking process, which is valuable 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 concise, consisting of two short sentences (bilingual). It front-loads the core action and then presents the critical warning. Every sentence earns its place without redundancy or unnecessary detail.

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

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

For a destructive, single-purpose tool with one optional parameter and no output schema, the description is complete. It covers the operation, the irreversible consequence, and the parameter default behavior (via schema). An agent has enough information to invoke it correctly and safely.

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

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

The input schema already describes the only parameter 'objects' with 'Object names; omit to use the current selection.' Since schema description coverage is 100%, the description does not need to add parameter details. The description doesn't add further semantic nuance beyond the schema, so a baseline of 3 is appropriate.

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

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

The description clearly states the tool's action: 'Collapse (apply and delete) the entire modifier stack of an object, baking the result into the base object.' It uses a specific verb and resource, and the scope ('entire modifier stack') distinguishes it from sibling tools like mod_remove or mod_disable, which target individual modifiers. The purpose is unambiguous.

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

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

The description provides a usage condition ('only do it when you are happy with the result') but does not explicitly mention alternatives or when not to use it. It implies that it's a final destructive step, but there is no guidance toward sibling tools for less destructive modifier management, such as mod_remove for removing a single modifier. This leaves some inference to the agent.

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 annotations already signal mutating/destructive behavior (readOnlyHint=false, destructiveHint=true). The description adds the intended operational effect—attaching an object to a target at a time—but does not disclose details like whether existing constraints are replaced, whether keyframes are created, or how the scene changes beyond the attachment.

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