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

With no annotations provided, the description must disclose behavioral traits itself. It mentions 'verified' and 'reuse' but does not explain what verification entails, what happens when reuse is not possible, what constraints are created, or if any destructive side effects occur. This is a significant gap for a mutating 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?

A single sentence that is front-loaded with the core function ('Create or reuse') and contains zero extraneous words. It is appropriately sized for the relatively simple action it describes.

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 four parameters with zero schema descriptions, no annotations, and an output schema, the description is far from complete. It omits parameter semantics, usage context, and behavioral details (e.g., verification process, side effects). An output schema exists but does not compensate for the missing execution guidance.

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

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

Schema description coverage is 0% and the description mentions none of the four parameters (armature_name, end_bone, target_name, chain_length). It does not add any meaning beyond the raw schema, failing to compensate for the undocumented parameters. The agent would have no idea what values to supply for target_name or chain_length.

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 ('Create or reuse') and explicit resources ('world-space paw target' and 'IK constraint') on a 'verified limb end bone'. This clearly distinguishes the tool from siblings like key_paw_pose (posing) and discover_limb_chains (discovery), so an agent can immediately understand its role.

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

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

No guidance is provided on when to use this tool versus alternatives, nor any exclusions. It does not mention prerequisites like prior verification via inspect_rig or discover_limb_chains, nor compare to other IK-related tools. The intended call context is left entirely to inference.

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

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

With no annotations, the description alone must disclose behavioral traits. It states the destructive action ('delete') but omits details such as whether the operation is reversible, requires existing keyframes, or has side effects on the animation. The singular sentence provides no additional behavioral context.

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

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

The description is a single, front-loaded sentence with no redundancy. It is concise, but the extreme brevity sacrifices informational value; it could be slightly expanded without losing conciseness.

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

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

The tool has 4 parameters (3 required), no parameter descriptions, and no behavioral context. The description does not explain typical usage, how to locate a keyframe, or what the outcome looks like. It is far from complete for an agent to correctly invoke it without external knowledge.

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

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

Schema description coverage is 0%, so the description must compensate by explaining parameter meanings. It does not mention how to identify the keyframe (e.g., via object_name, data_path, frame) or what the index parameter does. The description adds no semantic value beyond the schema's field names.

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 (delete), the resource (keyframe), and the context (animated object property). It is specific enough to distinguish from sibling tools like insert_keyframe or set_keyframe_interpolation, which are complementary operations.

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

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

The description offers no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. The tool's purpose is self-evident, but it fails to address scenarios like checking existing keyframes or differences from other keyframe-related tools.

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

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

With no annotations provided, the description carries the full burden of disclosing behavioral traits. It does not state whether the operation is read-only, what side effects it might have, or how it interacts with the armature. The mention of 'candidates' hints at a non-destructive process, but this is not confirmed. The description is purely operational and lacks transparency about effects beyond the immediate action.

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 with no fluff. The purpose is front-loaded in the first sentence, and the second adds a crucial usage hint. It earns a high score for efficiency and structure, though not a perfect 5 because it does not elaborate on any edge cases or clarifications.

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 of the tool as part of a larger rigging pipeline and the presence of an output schema, the description is moderately complete. It does not explain how the discovered chains are returned or how the 'candidate' approach integrates with subsequent tools like create_limb_ik. The description is serviceable but leaves the agent to infer the exact role and output format, which is only partially covered by the 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?

Schema description coverage is 0%, so the description must compensate by explaining parameters. It does not mention armature_name or minimum_chain_length at all. While the parameter names are somewhat self-explanatory, the description adds no context about their meaning, defaults, or how they affect the discovery process. This is a significant gap given the low coverage.

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

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

The description states a specific action ('Discover') on a specific resource ('weighted deform-bone chains') with a clear filter ('that geometrically resemble front or rear limbs'). This is clear and distinct from siblings like probe_bone_deformation, though it does not explicitly name an alternative. It slightly loses a point for not explicitly differentiating from the sibling that performs deformation probing, despite implying a complementary role.

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

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

The phrase 'Treat roles as candidates until deformation probing confirms them' implies this tool is a preliminary step before probe_bone_deformation, giving some usage context. However, it does not explicitly state when to use this tool versus others, nor does it provide exclusions or conditions. The guidance is implied rather than explicit.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It does specify the data types sampled (world transforms, camera visibility, bounding boxes) and the exact-frame sampling, which hints at a read-only evaluation. However, it doesn't disclose the return format, any side effects, or how the optional 'frames' parameter behaves when omitted. This is adequate but has clear gaps around precise behavior.

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

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

The description is a single, efficient sentence that front-loads the action and resource, followed by the purpose. There is no wasted wording; every element earns its place. It is concise and well-structured, making it easy for an agent to parse quickly.

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 low complexity (one optional parameter) and the presence of an output schema, the description covers the core functionality well. It explains what data is sampled and for what purpose. The main gap is the lack of explicit guidance on parameter behavior (null frames) and the absence of any note on side effects (though likely read-only). Overall, it is reasonably complete for its simplicity.

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

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

Schema description coverage is 0%, so the description must compensate. It adds meaning by linking the 'frames' parameter to 'exact frames', implying that the parameter specifies which frames to evaluate. However, it doesn't explain the default behavior when frames is null (e.g., whether all frames are evaluated) or any constraints on frame values. This is partial compensation but not complete.

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 ('sample') and a clear resource ('evaluated world transforms, camera visibility, and bounding boxes') with a clear purpose ('for numeric verification of motion and spacing'). It clearly differentiates from siblings like inspect_scene or inspect_object_animation by focusing on quantitative evaluation at exact frames rather than general inspection.

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 explicit guidance on when to use this tool versus alternatives. It doesn't mention conditions, exclusions, or contrast with any sibling tool. The phrase 'for numeric verification' implies a use case, but there's no direct statement of when to prefer it over other inspection tools, leaving the agent to infer.

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

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

With no annotations provided, the description must carry the full burden of behavioral disclosure. It mentions importing with components and optional normalization, but fails to disclose side effects such as scene modification, collection creation (despite a collection_name parameter), or whether existing assets are overwritten. The absence of any statement about safety or prerequisites leaves significant behavioral gaps.

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

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

The description is two sentences with no redundant words. The core purpose is front-loaded, and the optional normalization is stated clearly. Every sentence carries meaningful information without waste.

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

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

Given the complexity of importing a 3D asset, the description leaves many operational details unaddressed: it does not mention output formats (though an output schema exists), prerequisites (e.g., Blender running), error handling, or the impact on the current scene. The description is insufficient for an agent to understand the full context of the 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?

Schema description coverage is 0%, so the description must explain all parameters. It implicitly covers glb_path ('GLB/glTF asset') and normalize_size ('normalize its largest world dimension'), but completely omits collection_name, which is a parameter. The partial coverage does not compensate for the schema's lack of descriptions.

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

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

The description clearly states a specific verb ('Import') and resource ('GLB/glTF asset'), and lists the included components (PBR materials, armature, skin weights, animation clips). It distinguishes the tool from sibling inspection and animation tools by stating the import action explicitly.

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

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

The description implies the tool is for importing assets, which is clear from the title and action, but it does not explicitly state when to use it or when not to, nor does it name alternatives. Given the sibling list, an agent could infer usage, but no direct guidance is 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?

With no annotations provided, the description must disclose behavioral traits, but it only states the primary action (set value and insert keyframe) without detailing side effects, such as whether existing keyframes are overwritten, how the index parameter affects behavior, or error conditions. It also does not specify whether the operation requires any specific scene or animation context. This is minimal disclosure 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 a single, efficient sentence that front-loads the core purpose before mentioning data paths. There is no unnecessary verbiage or redundancy. It is appropriately sized for the information it contains, though it could benefit from a more structured breakdown.

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

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

For a tool with six parameters, no annotations, and an output schema, the description is insufficient. It does not explain the role of index (beyond default -1), what frame means in the timeline, or the interpolation choices. It also omits any mention of prerequisites or consequences (e.g., whether the object must be selected). The description leaves significant gaps for an agent to call the tool correctly.

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

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

Schema description coverage is 0%, so the description must compensate by explaining parameter meanings. It only partially clarifies data_path (by listing examples) and hints at value ('optional property value'), but it does not explain frame, index, interpolation, or object_name. Given six parameters, this leaves most parameters underspecified, forcing the agent to infer or guess.

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 ('insert a keyframe') and identifies the target resource ('optional property value' on 'data paths'). It gives concrete examples of data paths (location, rotation_euler, scale, custom properties), which helps clarify the tool's scope. However, it does not explicitly differentiate from the sibling key_pose_bone, which likely targets bone properties, leaving some ambiguity about whether this is for object or bone keyframing.

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 by listing relevant data paths (location, rotation_euler, scale), suggesting it is intended for object properties rather than bone properties. However, it provides no explicit guidance on when to use this tool over alternatives like key_pose_bone or set_keyframe_interpolation, nor any when-not conditions. The usage is only inferred, not stated.

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

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

No annotations are provided, so the description must convey behavioral traits. It does explain the frame sampling behavior ('If frames are omitted they are evenly sampled across the timeline'), which is useful. However, it doesn't disclose output format, potential performance costs, or side effects of rendering, leaving gaps in transparency.

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

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

Three concise sentences: purpose, usage context, and a parameter behavior note. Front-loaded with the main action, no wasted words, and each sentence 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?

The tool has 4 parameters, no output schema, and no annotations. The description covers the purpose and one parameter behavior but omits details on return value (e.g., file path, format), tile sizing semantics, and how the 'sample_count' interacts with 'frames'. An agent calling this correctly would need more guidance, but the core purpose is clear.

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

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

Schema description coverage is 0%, so the description must clarify parameters. It only addresses the 'frames' parameter (even sampling when omitted). The meanings of 'tile_width', 'tile_height', and 'sample_count' are not explained, relying on parameter names that may be ambiguous. This is insufficient given the zero 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 the action ('Render') and the resource ('animation frames'), producing a 'labeled contact sheet'. This distinguishes it from siblings like render_frame (single frame) and inspect_object_animation (data inspection). It is specific and not a tautology.

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

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

Gives explicit context for use ('Use after edits to visually verify poses, timing, continuity, staging, and camera motion'), which is clear and actionable. It doesn't explicitly list alternatives or when not to use it, but the context is sufficient given sibling 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?

With no annotations, the description must disclose behavioral traits. It says 'Inspect' which suggests a read-only operation, but does not explicitly state that no modifications occur, nor does it mention behaviors like error handling when bones are not found, whether selected bones refers to a selection in the scene or the bone_names parameter, or any dependencies on rest pose. It is partially transparent but leaves gaps.

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

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

The description is a single, efficient sentence that lists multiple inspection facets without unnecessary fluff. It front-loads the primary action ('Inspect') and the key attributes in a compact manner, making it 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?

Even with an output schema present, the description is incomplete for an agent to correctly invoke the tool. It lacks information about required armature context, how to specify which bones to inspect, and whether any scene selection is needed. Given the tool's complexity and the presence of many similar sibling tools, the description should provide more operational context.

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

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

Schema description coverage is 0%, so the description must compensate for parameter meaning. It mentions 'selected bones' but does not explain the armature_name or bone_names parameters, their roles, types, or how they interact (e.g., bone_names defaults to null meaning all bones?). The description adds no value beyond the parameter names already present in 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 clear verb ('Inspect') and a specific resource ('rest-pose local X/Y/Z axes, hierarchy, dimensions, and mesh-weight coverage for selected bones'). It distinguishes from generic inspection tools by enumerating exact data attributes, though it does not explicitly contrast with sibling tools like inspect_rig or probe_bone_deformation.

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

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

No explicit guidance on when to use this tool versus alternatives is provided. The description implies an inspection context but does not state prerequisites, exclusions, or conditions that would select this tool over others in the sibling set (e.g., inspect_rig for overall rig structure or probe_bone_deformation for deformation specifics).

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

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

No annotations are provided, so the description carries the full burden. It enumerates the exact data returned, which gives a clear picture of the tool's output. The verb 'Get' strongly implies a read-only operation, though side effects and error behavior are not explicitly addressed. The specificity of the return data makes the behavior reasonably transparent.

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

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

The description is a single, compact sentence that lists the key data types in a scannable form. It is front-loaded with the verb and object, and every word contributes to the purpose. There is no filler or repetition.

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

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

The description gives a clear list of what the tool returns, and since an output schema exists, the return structure is covered. However, it does not address edge cases such as objects without animation data or whether the tool only works on visible objects. For a single-parameter inspection tool with an output schema, this 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?

There is only one parameter, object_name, but the schema provides no description (coverage 0%). The tool description adds no extra semantic detail about the parameter, such as naming conventions or format expectations. Since the agent must rely solely on the parameter name, this is a gap, though the parameter is straightforward.

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 ('Get') and a specific resource ('object animation data'), and enumerates the exact data types returned (actions, F-curves, keyframe values/handles, constraints, NLA strips). This clearly distinguishes it from sibling tools like inspect_scene or inspect_rig, which target different scopes.

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 for inspecting an object's animation data, but does not explicitly state when to use this tool over alternatives like inspect_rig or inspect_scene. No exclusions or alternative tool mentions are provided, so the agent must infer context from the tool name and scope.

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

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

No annotations are provided, so the description carries the full disclosure burden. It conveys that the operation is inspection (read-only) and enumerates the exact aspects inspected, which is genuinely informative. But it adds nothing beyond the action and scope list — no error behavior, return characteristics, or side-effect notes that the name and enumeration don't already imply.

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

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

A single ~20-word sentence that front-loads the verb 'Inspect' and efficiently enumerates the inspected aspects. Every word earns its place with zero filler.

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

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

The tool has one self-explanatory parameter and an output schema that covers return structure, so the description need not explain outputs. It fully enumerates the inspection scope. Minor gaps — no explicit sibling routing and no parameter-format guidance — keep it from a 5.

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

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

Schema description coverage is 0%, so the description must compensate for the single armature_name parameter — yet it never mentions the parameter at all. The name is self-explanatory, but no format, naming-convention, or qualification guidance is provided for the tool's only required input, leaving a gap at low 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?

Uses the specific verb 'Inspect' against a defined resource ('generated asset's armature') and enumerates six distinct aspects it covers: armature hierarchy, rest pose, pose transforms, deform flags, mesh bindings, and animation actions. This enumerated scope clearly distinguishes it from siblings like inspect_scene, inspect_bone_axes, and probe_bone_deformation.

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 broad scope across six aspects implies this is the general-purpose rig inspection tool, in contrast to narrower siblings like inspect_bone_axes (axes only) and probe_bone_deformation (deformation only). However, it never explicitly states when to prefer this tool over those alternatives or names any exclusion conditions, leaving the routing to inference.

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

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

No annotations are provided, so the description carries the full burden. It uses the verb 'Inspect' which implies read-only behavior, but it does not explicitly state safety, side-effects, or any requirements. It also does not describe what the output contains beyond the listed categories, which is insufficient for a tool with zero annotation coverage.

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

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

A single concise sentence that front-loads the purpose and enumerates the scope precisely. There is zero 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?

This is a simple zero-parameter tool with an output schema present, so the description does not need to detail return values. It adequately covers the scope of inspection. The only gap is the lack of explicit read-only declaration, but given the simple nature and output schema, it is largely 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?

With zero parameters, the schema has nothing to document. The description correctly lists what the tool inspects, satisfying the baseline of 4 for a no-parameter tool. It adds no parameter-specific meaning because none exists.

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 ('Inspect') and a clear resource ('animation-relevant scene state'), and enumerates the exact aspects covered (timeline, camera, objects, actions, strips, markers). This differentiates it from more specific sibling tools like inspect_object_animation and inspect_rig.

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

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

The description implies this is the broad scene inspection tool by listing multiple scene aspects, giving clear context for when to use it. However, it does not explicitly state when to prefer it over sibling tools or provide exclusions, so it stops short of a 5.

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

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

No annotations are provided, and the description does not disclose any behavioral traits beyond the action. It doesn't state whether the tool returns an image, writes a file, or just displays a view internally, nor any side effects, permission requirements, or performance implications. The description gives no contract information.

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

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

The description is a single, efficient sentence that leads with the main verb and then the comparison purpose. It is not verbose and gets to the point, but it lacks essential details, so it earns high marks for conciseness but not for completeness.

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 annotations, no output schema, and four undocumented parameters, the description is far from complete. An agent cannot determine the output format, parameter meanings, or appropriate use cases, leaving critical gaps for correct invocation.

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

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

Schema coverage is 0% and the description does not mention any of the four parameters (frames, tile_width, tile_height, sample_count). An agent cannot infer what 'frames' refers to, how tile size affects output, or what sample_count controls. The description fails to compensate for the lack of schema descriptions.

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

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

The description states a clear action (render a contact sheet), the subject (the model), and the context (mapped reference-video frames) with explicit comparison goals (pose, silhouette, timing, foot-contact). It is specific enough to separate it from render_frame and render_video_overlay, though it does not explicitly name alternatives.

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

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

There is no guidance on when to use this tool versus its siblings (e.g., render_video_overlay or render_frame). No exclusions, prerequisites, or conditions for selecting this tool are mentioned. An agent would have to infer the purpose from the description alone.

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

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

No annotations are provided, so the description must carry the full burden. It mentions 'key' implying a keyframe operation, but does not disclose side effects like overwriting existing keys, interpolation behavior, or whether it affects the entire rig or just the target. The two location modes are described, but broader behavioral context is missing.

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

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

The description is a single sentence with no wasted words. It packs the core action and the two modes efficiently. It is not verbose, but could be slightly more structured.

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

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

With five parameters (two required) and an output schema, the description is far too minimal. It lacks explanations for what a 'paw IK target' is, how to reference it via target_name, what 'frame' means, and the role of interpolation. The output schema covers return values, but the input semantics are under-explained.

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

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

Schema coverage is 0%, so the description must explain all parameters. It clarifies world_location vs world_delta by mentioning absolute location and delta, but frame, target_name, and interpolation are left unexplained. Given five parameters, this is insufficient.

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 (place and key) and the resource (paw IK target) with specifics about two modes (absolute or delta). It is distinct from siblings like key_pose_bone (which targets bones) and insert_keyframe (generic), though it doesn't explicitly differentiate.

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. It describes how to specify location (absolute or delta) but does not mention prerequisites, such as requiring an existing paw IK setup or when to prefer this over key_pose_bone. Sibling tools like create_limb_ik or key_pose_bone are not referenced.

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

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

With no annotations provided, the description must disclose all behavioral traits. It does state that only supplied channels are changed, which is a positive nuance. However, it does not mention whether existing keyframes are overwritten, how interpolation is applied, or any side effects on the rig. For a mutation tool, this is a significant gap; it says what it does but not the full implications.

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

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

The description is two concise sentences, front-loaded with the primary purpose. Every word adds value: the action, the target resource, the transform channels, and a key behavioral caveat. There is no filler or redundancy, making it efficient 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 tool with 7 parameters and 3 required, this description is thin. It does not mention the interpolation setting, which is a notable omission. It also does not explain the coordinate system or how the arrays are structured for location, rotation, and scale. While an output schema exists and likely covers return values, the description alone is insufficient for an agent to confidently make correct calls without inspecting the schema.

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

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

Schema description coverage is 0%, so the description must compensate. It mentions location, rotation (WXYZ quaternion), and scale, but it does not explain the format of these arrays (e.g., quaternion order, units, local vs world). It also omits any explanation of the interpolation parameter, which is not covered by the schema. The description provides only surface-level mapping of parameters, failing to give the necessary details for correct invocation.

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

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

The description clearly states the action (key), the resource (a generated rig's pose bone), and the specific data involved (local-space location, WXYZ quaternion, scale). It also notes 'Only supplied channels are changed,' which clarifies its scope and distinguishes it from a generic keyframe tool. The mention of 'generated rig' differentiates it from sibling tools like insert_keyframe or key_paw_pose.

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

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

The description does not provide any explicit guidance on when to use this tool versus alternatives. It does not say 'use for generated rigs only' or 'when you need to key a bone's transform.' The only hint is the phrase 'only supplied channels are changed,' which is a behavioral note, not a usage context. No alternatives are mentioned, so an agent is left to infer the tool's role.

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

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

With no annotations, the description carries the full burden. It transparently states this is a read-only check that reports current state (open file, version, scene). It doesn't explicitly mention side effects (none implied) or error behavior, but for a simple ping-style tool, this is adequate. The description provides more behavioral context than a bare 'ping' would.

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

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

A single, front-loaded sentence with no wasted words. The purpose is stated first, followed immediately by the expected output. 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?

The tool is simple, has no parameters, and the output schema already documents the return values, so the description only needs to convey the intent and scope. It does so clearly enough for an agent to know what to expect. It falls short only because it doesn't mention when to use it (e.g., as a health check), but given the simplicity, this 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?

There are zero parameters and schema coverage is 100%, so the schema fully describes the input surface. The description doesn't need to add parameter details, and it doesn't mislead. The baseline for zero params is 4, and the description appropriately focuses on behavior rather than parameters.

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

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

The description clearly states the verb 'check' and the resource 'Blender bridge', and specifies exactly what it reports: open file, Blender version, and scene. It distinguishes itself from the sibling inspection tools (e.g., inspect_scene, inspect_object_animation) by focusing on connectivity/status rather than detailed scene analysis.

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 the many alternative inspection tools. It doesn't mention that it's a lightweight health check or that inspect_scene might be more appropriate for deeper scene queries. An agent would need to infer usage context 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?

No annotations are provided, so the description must disclose behavior itself. It does state that the operation is temporary ('restore the pose') and that it measures mesh deformation, which implies it requires an evaluated mesh. However, it does not mention potential side effects, prerequisites (e.g., mesh existence), or whether the armature must be selected. Overall, it is somewhat transparent but lacks completeness.

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

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

The description is a single sentence that front-loads the primary action (temporarily rotate, measure, restore) and ends with the output (strongest effective axis). It is concise with no redundant words, earning full marks for structure.

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

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

Given the tool's complexity (temporary mutation, measurement, restoration) and the lack of annotations, the description provides the core workflow but omits potential failure conditions, prerequisites, and any interaction with scene state beyond pose restoration. Since an output schema exists, return format is covered, but other contextual info is missing. A 3 reflects that it is minimally adequate but leaves gaps.

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

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

Schema description coverage is 0%, so the description must compensate for parameter meaning. It fails to explain angle_degrees beyond its name, and does not connect it to the rotation described. The parameter names (armature_name, bone_name) are relatively self-explanatory, but the optional angle_degrees is not contextualized, leaving the agent to guess its role.

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 and resource: temporarily rotating a bone and measuring mesh deformation to find the strongest axis. It distinguishes from siblings like inspect_bone_axes (which just inspects axes) and key_pose_bone (which sets poses) by emphasizing the deformation measurement and restoration. This is a unique, well-defined 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 gives no explicit guidance on when to use this tool versus alternatives. It does not mention that this is for analyzing deformation influence or when to prefer it over inspect_bone_axes. There is no 'when to use' or 'when not to use' 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?

With no annotations, the description carries the full burden. It mentions that the result is 'an image the model can see,' implying a read-only render output, but does not state whether the operation modifies the scene, requires specific permissions, or has any side effects. The lack of explicit read-only or non-destructive disclosure is a 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 a single sentence that is concise and front-loaded with the primary purpose. It is not verbose, but it is under-specified in terms of detail. Efficiency is good, but the brevity contributes to other gaps.

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 parameters and no output schema, the description must explain enough to call it correctly. It does not mention parameter meanings, default values, or what the returned image includes (e.g., background transparency). An agent would need to guess how to set resolution or what 'exact' means. This is incomplete.

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

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

The input schema has 4 parameters (frame, transparent, resolution_x, resolution_y) with 0% schema description coverage, and the description provides no explanation of any of them. The description only states the tool renders a frame, leaving the meaning of the parameters entirely to the schema, which has no descriptions. This is inadequate for correct parameter usage.

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 core function: rendering an animation frame and returning it as an image for the model to see. The verb 'render' and resource 'animation frame' are specific. It does not explicitly differentiate from sibling tools like render_video_overlay, but the core purpose is unambiguous.

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

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

No guidance is provided on when to use this tool versus alternatives. The description does not mention conditions, prerequisites, or exclusions. An agent cannot tell from the description whether to choose render_frame over inspect_scene or render_video_overlay.

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

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

No annotations are present, so the description carries the full burden. It says 'render' but does not disclose side effects (e.g., state mutation), prerequisites (e.g., video reference setup), or output details. Behavioral transparency is limited to the immediate action.

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 concise single sentence, front-loading the action. However, its brevity sacrifices critical details; it is efficient but lacks structural organization that could convey more information.

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

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

For a 4-parameter tool with no annotations or output schema, this description is incomplete. It omits usage context, parameter semantics, and behavioral effects, making it difficult for an agent to call correctly without additional information.

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

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

Schema description coverage is 0%, and the description does not explain any parameter. Only 'frame' is implicitly related to the rendering purpose; 'label', 'resolution_x', and 'resolution_y' are entirely unexplained.

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

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

The description states a specific verb ('render') and resource ('Blender timeline frame') with the compositing over a mapped reference-video frame. It clearly differentiates from generic render_frame by describing the overlay compositing, though it does not explicitly name the 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?

No guidance on when to use this tool versus render_frame or inspect_video_overlay. The purpose implies it is for final overlay output, but no context or exclusions are provided.

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

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

With no annotations provided, the description carries full behavioral burden. It states the action but fails to disclose important behavior: saving the current file overwrites the existing file (destructive), and does not describe what happens on invalid paths, error handling, or whether the operation is reversible. The description is minimal and does not prepare the agent for consequences.

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

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

The description is a single, concise sentence that is front-loaded with the primary action and immediately clarifies the two modes. There is no wasted wording or redundant detail; 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?

Given the tool's simplicity (one optional parameter) and the existence of an output schema, the description is reasonably complete, but it omits critical context such as overwrite behavior, error outcomes, and whether the operation is reversible. A save operation with potentially destructive overwrite deserves more explicit caveats. The minimalism creates a 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?

The schema has zero descriptions for the 'filepath' parameter, so the description must compensate. It adds useful semantics by specifying that the path must be an 'explicit absolute path', and implies that a null value saves the current file. However, it does not detail format requirements, validation, or behavior beyond that. This is a partial compensation for the 0% 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 the tool's verb ('Save') and resource ('.blend file'), and distinguishes two distinct behaviors: saving the current file or saving a copy to a specified path. This is specific and unambiguous, and it is naturally distinct from the sibling tools (which are inspection, animation, rendering, etc.).

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

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

The description does not provide any guidance on when to use this tool versus alternatives. It mentions two modes (save current vs. save copy) but does not explain when to choose one over the other, nor does it mention any prerequisites, side effects, or exclusions. No alternatives are referenced.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It mentions moving the timeline and evaluating the dependency graph, but it does not clarify whether this is a read-only operation, whether it alters any persistent state, or what side effects (if any) occur. It also doesn't mention requirements like the presence of a scene or rig. The description is thin on behavioral details.

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

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

The description is a single sentence with no redundant words. It front-loads the action ('Move the timeline') and then specifies the precision ('exact frame/subframe'). It is appropriately concise and well-structured.

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

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

Despite having an output schema (not shown), the description is otherwise sparse. It does not explain what the dependency graph evaluation returns, any prerequisites (e.g., a loaded scene), or how this tool fits into a workflow with siblings. The lack of usage guidance and parameter details makes it incomplete for an agent to understand the tool's role and effects.

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

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

The schema provides no descriptions (coverage 0%), so the description must compensate. It mentions 'frame/subframe' but doesn't explain what 'frame' represents (absolute timeline position?), units, or how 'subframe' is used (fractional interpolation?). It gives only a minimal hint that the combination allows an 'exact' position, leaving the agent to guess at the parameter meanings.

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 ('Move') and clearly identifies the resource ('timeline') and the action ('evaluate the dependency graph at an exact frame/subframe'). It is not a tautology, but it doesn't explicitly differentiate from the sibling 'set_timeline', which could be confused conceptually. The purpose is understandable but could be more precise about the role of 'set_timeline' versus this tool.

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

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

The description provides no context on when to use this tool relative to siblings like 'set_timeline', 'insert_keyframe', or 'evaluate_animation'. It doesn't state when this is the appropriate choice (e.g., for evaluating a specific frame vs. setting a range) or when it should not be used. The agent would have to infer usage from the name and 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?

No annotations are provided, so the description carries the full burden. It only mentions the optional frame range restriction, but offers no information about side effects (e.g., whether unchanged keyframes are ignored), failure modes, idempotence, or any prerequisites. For a mutation tool, this is insufficient transparency.

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

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

The description is a single 14-word sentence that is front-loaded with the primary action and the key scope modifier. Every word earns its place, and there is no 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?

For a tool with 5 parameters, no schema descriptions, and no annotations, the description leaves out nearly all essential context. An agent cannot infer the meaning of object_name, data_path, interpolation, or how frame_start/frame_end interact with matching. This is inadequate for correct invocation.

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

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

Schema description coverage is 0%, and the description adds no explanation for any parameter. It only mentions 'matching keyframes' and 'frame range' but does not clarify that object_name and data_path are required to match keyframes, nor explain the interpolation enum values. The description fails to compensate for the sparsely documented 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 ('Change'), a clear resource ('interpolation for matching keyframes'), and an optional scope ('frame range'). This distinguishes it from sibling tools like insert_keyframe and delete_keyframe, which deal with keyframe creation/deletion rather than interpolation changes.

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, nor any exclusions or conditions. It simply describes what the tool does without contextualizing it among the many animation-related siblings.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It simply says 'set', implying mutation, but does not mention whether changes are reversible, whether keyframes are affected, or any prerequisites. This is a significant gap for a mutation tool in an animation pipeline.

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

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

The description is a single sentence with no unnecessary words. It is front-loaded and efficient, though it could add more information without becoming verbose.

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 a simple setter, and an output schema exists (though not shown), so return values are not a gap. However, for a tool among many animation siblings, the description lacks usage context, side effects, and any indication of when it should be invoked. This makes it incomplete for an agent navigating the toolset.

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

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

Schema description coverage is 0%, so the description must compensate. 'Animation range' maps to frame_start and frame_end, and 'frames per second' maps to fps, providing some semantic grounding. However, it does not explicitly explain each parameter's role or any constraints, leaving ambiguity about the exact meaning of 'range'.

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: setting the animation range and frames per second. This distinguishes it from siblings like set_current_frame (single frame) and keyframe tools. It could be more specific about what 'range' means, but it is unambiguous enough for selection.

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

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

No guidance is provided on when to use this tool versus alternatives such as set_current_frame or insert_keyframe. The description does not mention exclusions or context, leaving the agent to infer usage from the tool name and parameters.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the tool modifies the compositor (attaches video) and explains the video_frame_offset behavior, which is useful. However, it does not mention side effects such as overwriting existing references, whether the operation is reversible, or any prerequisite like video_path validity. This is a partial disclosure for a state-changing 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 two sentences with no filler. It front-loads the primary purpose and then adds a param-specific detail. Every clause earns its place, and the structure 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 tool with 3 parameters and an output schema, the description gives enough to call correctly: it states the action, the effect, and the timing offset. It does not mention any return value, but that is covered by the output schema. The main gap is lack of guidance on when to use this vs sibling overlays, but that is more of a usage guideline issue. Overall, an agent can safely invoke it without missing critical context.

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

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

Schema description coverage is 0%, so the description must compensate. It explicitly explains video_frame_offset's effect and implies model_opacity's role via the rendering statement. video_path is self-explanatory by name. While not exhaustive, the description provides meaningful context beyond the schema for two parameters, leaving video_path clear enough.

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 ('attach'), a resource ('reference video to Blender's compositor'), and a clear purpose ('pose-by-pose rotoscoping'). It distinguishes from siblings like inspect_video_overlay and render_video_overlay by focusing on setup rather than inspection or rendering.

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

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

The description implies usage (necessary for rotoscoping) but does not explicitly state when to use this tool vs alternatives or mention any exclusions. There is no mention of when a different tool like inspect_video_overlay would be more appropriate, leaving the agent to infer from the purpose.

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

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

With no annotations provided, the description must fully disclose behavioral traits. It does not state whether the tool modifies the scene, requires specific setup (e.g., existing IK targets), or how it signals flagged displacement (e.g., error, return value). The description is silent on side effects and limitations, which is a significant gap for a tool that presumably validates animation.

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

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

The description is a single, efficient sentence that front-loads the core actions and key concepts. It contains no filler or redundant phrasing, making it concise 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?

Given the tool's complexity (four parameters, one required), the lack of annotations, and zero schema coverage, the description is incomplete. It fails to explain parameter roles, usage context, or behavioral side effects. While an output schema exists (noting that return values are covered), the missing information about inputs and behavior leaves significant gaps for an agent attempting to use the tool correctly.

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

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

Schema description coverage is 0%, so the description must explain parameter meanings. It hints at concepts like 'paw IK targets' (likely target_names), 'walk' (frames), 'ground-contact' (ground_z), and 'displacement' (contact_tolerance), but does not explicitly map these terms to the actual parameters. An agent would struggle to correctly assign values without additional context.

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

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

The description states the tool's purpose with specific actions ('sample', 'identify', 'flag') and resources ('paw IK targets', 'ground-contact frames', 'displacement'). It clearly distinguishes this as a validation tool, setting it apart from sibling tools like key_paw_pose, create_limb_ik, and inspect_scene, which focus on creation or inspection rather than validation of a walk cycle.

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, nor does it specify prerequisites or exclusions. It does not mention that it should be used after creating IK targets or before rendering, leaving the agent to infer the appropriate context from the tool name and sibling list.

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