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

The annotations already declare destructiveHint=true, and the description adds little behavioral detail beyond the input-freshness warning. It does not explain what activation actually changes, whether it is reversible, or what impact it has on the current scene/session.

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

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

The description is two short sentences with no filler. The action is front-loaded and the prerequisite instruction 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 one-parameter tool, the core usage is stated, and the list_scenes dependency is mentioned. However, because this is a destructive state-changing operation with no output schema, the description omits what activation does to the current scene or session, leaving some context 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?

With schema description coverage at 0%, the description compensates by defining index as a scene index returned by list_scenes and by emphasizing that indices must be refreshed before use. This adds meaningful meaning beyond the raw integer schema.

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

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

The description uses a specific verb ('Activate') and identifies the resource as 'a scene index returned by list_scenes', which makes the target of the operation clear. It does not explicitly differentiate this from sibling tools like open_scene or new_scene, though the reference to list_scenes provides useful 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 a clear prerequisite: refresh indices before use, implying the agent should call list_scenes first. It does not explicitly explain when to choose activate_scene over alternatives such as open_scene, but the usage context is reasonably 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 mark this destructive and not read-only, so the description's job is lighter. It still adds meaningful behavior: delta rotations reference a pre-edit frame, default 0, and it advises a verify workflow. This clarifies the relative nature of the animation changes beyond what the schema states.

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

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

Two sentences with the main purpose front-loaded and the key behavioral nuance following immediately. Every sentence earns its place, and there is no fluff 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?

For a tool with a complex nested keyframe schema, two top-level parameters, no output schema, and destructive annotations, the description is too thin. It does not explain how keyframes should be structured, what happens to existing animation, or how interpolation behaves, so an agent would need to inspect the schema and likely cascadeur_inspect_tool to use it 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 description clarifies the semantics of rotation_delta_degrees by explaining the pre-edit frame reference and default of 0. However, it adds no explanation for the keyframes structure, interpolation enum, or position/quaternion options, and the schema has minimal top-level property descriptions, leaving the agent partly reliant on nested schema names alone.

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

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

The description states a specific action ('Author body and finger animation') on a clear resource, and emphasizes the batch aspect that distinguishes it from single-pose tools like cascadeur_set_pose. It is not a tautology and gives the agent a concrete sense of what the tool accomplishes.

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 use for batch animation and suggests verifying via 'Read poses and render', but it never explicitly says when to prefer this tool over alternatives such as cascadeur_set_pose or cascadeur_set_keys. The 'batch' wording provides some context, but the when-not guidance is absent.

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 establish read-only, idempotent, non-destructive behavior. The description adds a meaningful caveat beyond those annotations: 'Presence is not proof of execution' warns that listed capabilities may not be invocable or succeed. It also signals that it reports actual editor methods rather than assumed ones.

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

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

Two short sentences, front-loaded with the main purpose and ending with an important caveat. Every word earns its place, with no repetition of the tool name or schema fields.

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 discovery tool, the description is complete: it states what will be discovered, including limitations, and warns about over-trusting presence. Annotations cover the safety profile, so no critical guidance is missing.

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

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

The tool has zero parameters, so the 100% schema coverage leaves nothing undocumented. The description appropriately focuses on what information the call returns 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 uses a specific verb 'Discover' and names concrete resources: installed app tools, actual editor methods, license flags and limitations. This clearly positions it as the general capability-introspection tool alongside siblings that operate on scenes, objects, or specific actions.

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

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

It clearly implies use before working with other tools, to learn what is installed and allowed. It does not explicitly name alternatives or say when not to use it, but the zero-parameter discovery purpose makes the context 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 destructiveHint=true, but the description adds little behavioral context. It does not state that a file is written to the specified path, how overwrite=false behaves, or whether the scene is modified. The filename tip indirectly hints at overwrite risk but leaves the actual file-saving behavior ambiguous.

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, followed by a single tactical tip. It is brief and does not ramble, but the brevity omits important parameter and behavior details. Still, 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 tool with 4 parameters, no output schema, and no parameter descriptions, this description is incomplete. It does not clarify the role of the required path parameter, the meaning of overwrite, or the failure behavior when the file already exists, leaving an agent to guess.

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 undocumented parameters. It only hints at path usage ('Use distinct filenames per pose') and says nothing about width, height, or overwrite semantics, leaving most parameters 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 action, 'Render a PNG of the active viewport,' and the return format, 'return it as an MCP image.' This clearly distinguishes it from sibling tools such as export_fbx or set_view_mode, making the tool's purpose unambiguous.

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

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

The description provides no guidance on when to use this tool versus alternatives like export_fbx or get_camera. The only usage note, 'Use distinct filenames per pose,' addresses repeated captures but does not help an agent decide when this tool is appropriate.

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

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

Annotations already flag destructive behavior and non-read-only status, so the description adds value by disclosing the license-check requirement and instructing the agent to verify skeleton, frame range, and axes in the receiving app. This reveals a non-obvious validation step and post-condition that an agent would otherwise not know.

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

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

The description is concise at two sentences and starts with the core action ('Export FBX'), but the first sentence's phrase 'after checking app license' is slightly ambiguous (prerequisite vs. behavior). Overall, each sentence earns its place and there is no fluff.

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 3 parameters, no output schema, and no schema descriptions, yet the description does not explain return values, error conditions, or mode semantics. It covers the license check and verification step, but otherwise leaves an agent guessing about what happens after invocation and how the parameters affect the export.

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 carries the burden of explaining parameters, but it does not address path, mode, or overwrite at all. While the parameter names and enum values are somewhat self-explanatory, the description adds no meaning to them and fails to compensate for the missing 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 specific verb ('Export') and resource ('FBX'), and clearly distinguishes the tool from its sibling 'cascadeur_import_fbx'. The additional mention of checking the app license and verifying the export adds specificity without muddying the core 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 phrase 'after checking app license' implies a prerequisite, and the verification step hints at a post-export workflow, but there is no explicit guidance on when to use this tool versus alternatives. No exclusions or conditions are stated, so the usage context 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?

The annotations declare destructiveHint=true, while the description frames the operation as purely for visual inspection, implying no destructive or persistent side effects. The description does not disclose any behavioral traits and directly conflicts with the annotation, so it earns the lowest score.

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 filler, front-loading the action and purpose. It is appropriately sized for a one-parameter viewport tool, with every word contributing 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 tool carrying destructiveHint=true and an undocumented parameter, this one-line description is not sufficient for safe invocation. It lacks side-effect disclosure, object name semantics, and usage alternatives, and it conflicts with the annotation, leaving critical context 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 gives only a bare array of strings with 0% description coverage. The description adds the key semantic that these strings correspond to 'body or finger controls', narrowing the parameter domain and differentiating them from generic scene objects. Still, it does not specify naming conventions, path syntax, or whether controls must already exist, so the compensation is partial.

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 ('Frame') with a resource ('body or finger controls') and a clear purpose ('visual inspection'), making the operation understandable. It implies a viewport/camera task distinct from sibling tools like capture_viewport or set_view_mode, 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?

No guidance is provided for when to use this tool versus related tools such as select_objects, set_camera, or capture_viewport. The phrase 'for visual inspection' only weakly implies an inspection use case, without conditions, 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 readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description does not need to restate safety. It adds the purpose of restoring a view but no additional behavioral traits (e.g., what data is returned, format, or side effects). The description does not contradict the annotations, and with annotations covering safety, a 3 is appropriate for slightly enriching context beyond them.

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

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

The description is a single, front-loaded sentence with zero filler. It leads with the verb and resource, states the purpose, and contains no redundant information. Every word earns its place, making it a model of 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?

For a zero-parameter, read-only tool with annotations covering safety, the description is largely sufficient. It says what it reads and why. It does not specify the exact return format (e.g., position/rotation fields), but with no output schema and a simple getter, this is a minor gap. The complexity is low enough that the description is nearly complete, though a note about return value would push it to 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?

The tool has zero parameters, and the input schema is empty (100% coverage). The baseline for 0-parameter tools is 4, and the description requires no parameter explanation. There is no missing parameter information to compensate for, so a 4 is justified.

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'), a specific resource ('active viewport camera'), and the purpose ('restoring a view after hand/body closeups'). It clearly distinguishes from siblings like cascadeur_set_camera (write operation) and cascadeur_capture_viewport (likely image capture) without needing to name them 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 gives clear context for when to use the tool ('for restoring a view after hand/body closeups'), which tells an agent the intended scenario. It does not explicitly name alternatives or exclusions, so it stops short of a 5, but the purpose strongly implies when the read-only camera getter is appropriate versus a setter or capture 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds value by specifying that it returns 'unavailable values' and by framing it as a pre-edit step, which are behavioral details beyond the annotations. No contradictions.

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

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

Two sentences, no filler, and the primary purpose is front-loaded. The sentence 'Read before editing properties' efficiently adds usage context. 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 description covers the core purpose and gives a usage hint, but it does not explain the 'frame' parameter, which is crucial for time-dependent inspection. It also doesn't clarify what 'behaviours and data channels' concretely return, though annotations cover safety. For a tool with two parameters and no output schema, more detail on the frame semantics would make it complete.

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

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

Schema description coverage is 0%, so the description must compensate. It implies the 'object' parameter by saying 'an exact object', but it never explicitly maps to the schema, and it completely omits the 'frame' parameter, leaving its purpose (likely frame-specific inspection) ambiguous. This is a significant gap given no other 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 a specific verb ('Inspect') and resource ('an exact object's behaviours and data channels'), and adds a distinctive feature ('including unavailable values') that differentiates it from siblings like get_pose or list_objects. The phrase 'Read before editing properties' further clarifies its role as a pre-edit inspection 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 a clear usage context: 'Read before editing properties' implies it should be used before property-editing tools (like cascadeur_set_properties). It does not explicitly name alternatives or exclusions, but the context is enough for an agent to infer when to use it. A minor gap is not naming sibling tools that overlap.

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, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds useful output detail about WXYZ quaternions and Euler radians, but it does not describe return structure, error handling, or behavior for missing objects.

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 concise sentences with no filler. The core action is front-loaded, and the additional sentence about rotation formats adds a distinct, useful detail without redundancy.

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

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

For a simple read-only tool with strong annotations, the description is mostly adequate. However, since there is no output schema, the description should more clearly explain the return shape, such as whether translation and scale are included alongside rotation and how local versus global values are structured.

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

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

Schema description coverage is 0%, so the description must compensate, but it only weakly maps 'at a frame' to the frame parameter and 'transforms' to objects. It does not explain that objects is required, that objects has a 200-item limit, or that frame defaults to 0 and is constrained to 0-100000.

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 ('Read') and a specific resource ('local/global transforms at a frame'), making the tool's purpose clear. It implicitly contrasts with sibling set_pose, but it does not explicitly name or differentiate itself from related tools like get_object or sample_motion.

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 when-to-use guidance or alternatives. It implies the tool is for reading transforms at a frame, but it does not tell the agent when to prefer this over cascadeur_get_object, cascadeur_sample_motion, or cascadeur_set_pose, nor does it mention any prerequisites.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful scope by naming what will be inspected, but it does not disclose additional behavioral details such as the response format, whether counts include hidden objects, or any performance implications.

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

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

A single, compact sentence that communicates the tool's purpose and scope without any filler. Every word adds value, and the key subject ('current scene') is placed 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 zero-parameter, read-only inspection tool, the description covers the important inputs (none) and names the categories of output: scene, frame range, selection, and object counts. It would be slightly stronger if it mentioned that it returns a summary snapshot rather than detailed per-object data, but it is sufficient for an agent to decide whether to call it.

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

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

The tool has zero parameters, so there are no parameter semantics to clarify beyond what the schema shows. The description appropriately focuses on the output contents, which is the only meaningful information an agent needs for invoking 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 ('Inspect') and names the resource ('current scene') while enumerating concrete returned aspects: frame range, selection, and object counts. This clearly conveys what the tool does, though it does not explicitly differentiate it from the similarly named sibling cascadeur_status.

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 stated scope implies when to use the tool: whenever a summary of the current scene state is needed. However, there is no explicit guidance about when not to use it or which sibling tool (e.g., cascadeur_status, cascadeur_list_objects, cascadeur_get_pose) should be preferred for more specific queries.

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 non-read-only; the description adds valuable specifics: 'Animation replaces matching rig data' and the guidance to save a checkpoint and inspect skeleton mappings. This goes beyond the annotation flags without contradicting them.

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

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

Two short sentences contain the purpose, a key destructive caveat, and actionable workflow advice. The primary purpose is front-loaded and no words are wasted.

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

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

For a mutating tool with no output schema, the description covers the destructive risk but leaves the mode parameter largely undocumented and provides no guidance on expected results or prerequisites. It is not complete enough for confident mode selection without further inspection.

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 carry parameter meaning. It conveys that the path is workspace-relative via 'from the workspace,' and it hints at animation behavior, but it does not explain the mode parameter's scene/animation/model options or their effects.

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

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

The description opens with a specific verb and resource: 'Import an FBX from the workspace.' This is unambiguous and clearly distinct from sibling tools such as cascadeur_export_fbx and cascadeur_open_scene.

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

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

The description implies a usage context by warning that animation replaces matching rig data and advising a checkpoint, but it does not explicitly state when to use this tool versus alternatives, when not to use it, or what prerequisites exist.

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, idempotentHint=true, and destructiveHint=false. The description adds meaningful behavioral context beyond those annotations: it promises to read the live API without executing methods, which clarifies the safety profile and distinguishes live introspection from stale stubs. This is valuable extra transparency for an inspection 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 tight sentences with no filler. The primary function is front-loaded in the first sentence, and the second sentence adds a clear preference directive. 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 core purpose and safety profile are clear, and annotations cover mutation concerns. However, the tool has no output schema and no parameter descriptions, so the agent does not know how to construct 'path' or what the result format looks like. The sibling 'cascadeur_inspect_tool' is also left undifferentiated, leaving some selection and invocation details unresolved.

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 of the three parameters: 'path', 'root', or 'limit'. The enum values for 'root' are visible but their meaning is not clarified, and 'path' is entirely ambiguous without an example or format hint. Since schema coverage is low, the description should compensate but does not.

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

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

The description clearly states a specific action and resource: 'Read live Python API member names/signatures/docs without executing methods.' This is much more specific than a tautology and conveys the tool's introspection purpose. However, it does not explicitly differentiate from the similarly named sibling 'cascadeur_inspect_tool', so it misses the clearest possible sibling distinction.

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 'Prefer this over guessing from stale stubs' gives a clear usage context: use this tool when you need authoritative, current API information rather than relying on memory or outdated documentation. It does not name alternative tools or explicit when-not-to-use cases, but the context is strong enough to guide an agent's initial choice.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so no safety contradiction exists. The description adds that it exposes 'actual signatures,' which is a behavioral detail, but it does not clarify what the output looks like or how the optional path affects 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 one concise sentence plus a second benefit-focused sentence. It front-loads the core action and avoids filler, though it is slightly too terse to fully resolve ambiguity around 'discovered' and 'public attribute path.'

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 has three parameters and no output schema, the description leaves important gaps: it does not explain the 'editor' parameter, the expected return structure, or how path traversal works. The annotations cover safety, but an agent lacks enough context to reliably invoke this tool with the right arguments.

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

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

Schema description coverage is 0%, so the description must compensate. It explains 'name' as a tool/editor and 'path' as an optional public attribute path, which adds some meaning. However, the 'editor' boolean parameter is not explained at all, and the exact format of the path or how it interacts with the tool is left to inference.

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 ('Inspect') and identifies the resource ('a discovered tool/editor') plus the optional attribute path. It also states the benefit ('Exposes actual signatures for advanced scripts'), which helps distinguish it from a generic inspection tool. However, 'discovered' is somewhat vague and the distinction from the sibling cascadeur_inspect_api is not explicit.

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

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

The phrase 'for advanced scripts' implies when it might be useful, but there is no explicit guidance on when to choose this tool over alternatives like cascadeur_inspect_api. No triggers, prerequisites, 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is established. The description adds useful context about 'curated' actions and 'verification status', which goes beyond the structured annotations. However, it doesn't explain what verification status means or any other behavioral nuances like performance or filtering 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 concise sentence with no filler. It leads with the verb and resource, then lists the relevant categories. It's appropriately sized for a simple list operation and all words add 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 tool with one undocumented parameter and no output schema, the description leaves key gaps: it never explains how the 'query' parameter behaves, and 'verification status' is not elaborated. An agent cannot fully determine correct usage without additional inspection, making the description incomplete for the tool's 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?

The only parameter, 'query', has no description in the schema (0% coverage) and the tool description does not mention it at all. There is zero added meaning about how query filters results, what format it expects, or whether it matches action names, categories, or status. The agent receives no help understanding this parameter.

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

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

The description clearly states the tool lists curated menu actions and enumerates specific categories (physics, AutoPosing, retargeting, cycles, playback, visual review). The verb 'List' plus the resource 'menu actions' makes the purpose evident and distinguishes it from action-running or inspection siblings, though it doesn't name a sibling 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?

No guidance is provided on when to use this tool versus alternatives like run_action or inspect_tool. There is no mention of use cases, prerequisites, or situations where a sibling would be more appropriate, 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful behavior ('stable IDs and pagination') but does not elaborate on return contents, ordering, or default query behavior, so it only moderately exceeds 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?

A single front-loaded sentence with zero filler: verb, resource, filters, and key behaviors all in one compact phrase. Every word contributes.

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 listing tool with four optional parameters and no output schema, the description is nearly complete: it names the search dimensions, pagination, and stable identifiers. It would be stronger if it explicitly stated what fields the returned objects contain, but the core calling context is present.

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

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

Schema description coverage is 0%, so the description must carry semantics. It maps query to name substring, object_type to exact type, and limit/offset to pagination, which compensates for missing per-parameter docs. It does not explain defaults or null semantics, but those are visible 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?

Description uses a specific verb ('Find'), resource ('objects'), and explicit filtering criteria ('name substring and exact type'), plus meaningful operating traits ('stable IDs and pagination'). This clearly distinguishes it from sibling tools like get_object, select_objects, and list_scenes.

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 finding objects by name/type when listing/paging is needed, but it does not explicitly state when to prefer get_object, select_objects, or other sibling tools. No exclusions or alternative routing 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, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds useful behavioral context by specifying that it lists only 'open scene tabs' and that the output includes 'current indices and names,' which goes beyond a generic 'list scenes' phrasing.

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, then adds the two essential output components. There is no filler, 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 zero-parameter, read-only listing tool, this description is complete: it states the object being listed, the scope ('open'), and what information is returned ('current indices and names'). No output schema exists, but the description adequately covers the return contents. Annotations cover side-effect safety.

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

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

The tool has zero parameters, so the schema leaves no ambiguity. With no parameters to document, the description does not need to add parameter-level meaning, and the 0-parameter baseline of 4 applies.

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

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

The description uses a specific verb ('List') with a precise resource ('open scene tabs') and names the key output details ('current indices and names'). It clearly distinguishes this tool from siblings like cascadeur_list_objects, cascadeur_list_actions, and cascadeur_list_tracks by scoping to scenes.

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 through its listing semantics: use this when you need to enumerate currently open scene tabs before targeting one by index or name. However, it does not explicitly state when to prefer this over alternatives such as cascadeur_status, cascadeur_get_state, or cascadeur_activate_scene.

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 cover read-only and idempotent behavior, so the description need not repeat that. It adds value by specifying what data is returned (locks, visibility, keys, interpolation) and clarifies the distinction from layers, which is behavioral context. 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 description is two sentences with no unnecessary words. The primary action and scope are front-loaded, and the distinguishing note about layers is placed at the end. It is 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?

For a zero-parameter read-only list tool, the description covers what is listed and provides a distinction from layers. It does not specify the output format or scope (e.g., current scene), but given the simplicity and the presence of annotations, this is adequate for an agent to use correctly.

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

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

The tool has zero parameters, so the baseline of 4 applies per instructions. The description correctly avoids adding parameter details since none exist. It does not need to compensate for any schema gaps.

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 (List) and resource (animation tracks) and enumerates the specific attributes included (locks, visibility, keys, interpolation). It also adds a distinguishing note that tracks differ from additive animation layers, which helps separate it from layer-related tools. This is specific and 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 hints at usage by noting tracks differ from additive layers, implying this tool is for tracks rather than layers. However, it does not explicitly name alternative tools like list_actions or get_pose, nor does it state when to use this tool vs. those. Usage is implied but not directly 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 and readOnlyHint=false, so the agent knows this is a mutating operation. The description adds the prerequisite about valid mirror mappings, which is useful context beyond the annotations. However, it does not disclose what gets overwritten or changed (e.g., existing keys, curves, or transforms), which is notable for a destructive 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 concise—two sentences, front-loaded with the action and scope, followed by the requirement. No wasteful words. It could arguably be slightly more detailed, but it is efficient 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?

For a destructive tool with no output schema and only two parameters, the description is minimal. It does not explain the effect on existing animation data, the exact behavior of the interval flag, or how the objects array constrains the operation. An agent cannot fully predict what will be modified, which is a significant gap for a mutating 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 compensate. It links the interval parameter to 'current frame or selected interval' but does not explain the objects parameter—what objects mean, how they are identified (names, paths), or how they map to 'explicit controls'. The interval parameter is partially explained, but the primary required parameter remains semantically opaque.

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

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

The description states a specific action ('mirror') applied to a resource ('explicit controls') with a time scope ('current frame or selected interval'). It clearly distinguishes from sibling tools, none of which perform mirroring. However, 'explicit controls' is somewhat jargon-heavy and could be more precise (e.g., naming the object types or rig components affected).

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 naming the action and prerequisite ('Requires valid mirror mappings on the rig'), but it does not explicitly state when to use this tool vs alternatives like set_pose or animate_transforms, nor does it provide exclusions or conditions that would rule out other tools. Usage is implied rather than clearly instructed.

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 adds a meaningful qualifier: 'Existing tabs are preserved,' which clarifies that the destructive aspect is limited to creating a new tab rather than destroying existing scenes. This goes beyond the annotation, though it does not specify whether the new tab becomes active or what its initial contents are.

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

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

The description is two short sentences with no filler. The core action and the key safety qualifier are front-loaded, and every clause contributes meaningful 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 zero-parameter creation tool, the description provides essential purpose and the main side-effect caveat. No output schema exists, and the sibling tools cover related scene operations, so nothing critical is missing for an agent to invoke this correctly.

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

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

The tool has zero parameters and schema description coverage is 100%, so there are no parameter details the description needs to add. Per the zero-parameter baseline, this is handled appropriately.

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 'Create', the object 'a new scene tab', and the scope 'Existing tabs are preserved.' This distinguishes it from related siblings like open_scene, save_scene, and activate_scene, which load, persist, or switch scenes rather than creating a fresh tab.

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 directly stated: create a new scene tab. The note that existing tabs are preserved also clarifies when it is safe to use, since it will not discard current work. However, it does not explicitly name alternatives or edge cases where a different tool should be preferred.

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, so the description's burden is lower. It adds useful context about file format and path restriction, but it does not disclose that opening a scene may replace the current scene or discard unsaved changes. 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?

A single sentence that front-loads the verb and object and includes the key path constraint. There is no filler or redundant repetition 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 one-parameter open-operation with destructiveHint=true, the description covers the core facts: what file to open, where the path must live, and that it is a .casc scene. It could mention the effect on the current scene, but annotations already communicate destructiveness and the tool is simple enough that 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?

With 0% schema description coverageci, the description carries the full weight for the only parameter. Stating that the path must be an 'absolute path inside the workspace' adds essential meaning beyond the bare 'path' title, and the .casc reference implies the expected file type.

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

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

The description clearly names the action ('Open'), the resource (a .casc scene), and a specific constraint (absolute path inside the workspace). This distinguishes it from siblings like cascadeur_new_scene, cascadeur_activate_scene, or cascadeur_list_scenes without further digging.

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: open an existing .casc scene file from disk. However, it never explicitly states when to prefer this over alternatives such as cascadeur_new_scene or cascadeur_activate_scene, nor does it mention when not to use 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?

The description adds useful behavioral detail beyond the destructiveHint annotation: 'Frame 0 is protected' identifies a special-case constraint, and 'save a checkpoint first' reinforces the irreversibility implied by destructiveHint=true. It does not contradict the annotations and provides context an agent needs before mutating keyframes.

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

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

Two short sentences, zero filler. The purpose is front-loaded and the safety warning is placed second, giving the agent both the action and the key constraint in the minimum possible space.

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 mutation tool with no output schema and no parameter documentation, the description is minimally viable: it states the operation, protects frame 0, and advises a checkpoint. However, it does not specify how tracks should be named, what happens when frame 0 is included (skipped or error), or how success/failure is reported.

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

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

With 0% schema description coverage, the description needed to compensate, but it only hints at the 'tracks' parameter via 'explicit tracks' and says nothing about the 'frames' parameter, its relationship to keys, or valid frame semantics. The array schemas are left to carry the entire meaning.

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

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

The description opens with a precise verb and object: 'Remove keys from explicit tracks.' This clearly identifies the operation and distinguishes it from sibling tools like cascadeur_set_keys (opposite) and cascadeur_list_tracks (inspection). The qualifier 'explicit tracks' signals the operation is limited to the tracks supplied, not implied ones.

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 choose this tool over alternatives such as cascadeur_set_keys or cascadeur_set_pose, and no exclusionary context. The only operational advice is 'save a checkpoint first,' which is a safety precondition rather than a tool-selection guideline.

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 establish read-only, idempotent, and non-destructive behavior, so the bar is lower. The description adds a valuable caveat: names alone do not establish axes, which tells the agent not to infer axis orientation from control names when interpreting the rig summary.

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

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

Two short sentences, front-loaded with the main inspection scope and followed by a single caveat. No filler or repetition; every phrase contributes either to what the tool covers or to how the result should be interpreted.

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 zero-parameter read-only summary, so invocation requires no additional context. The description names the categories of rig elements covered and warns about the axes caveat, which is sufficient for an agent to know when to call it and what to expect at a high level.

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

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

The input schema has zero parameters, so there is nothing for the description to document. With schema coverage at 100% and no parameters, the baseline of 4 applies; the description does not need to add parameter semantics.

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 ('Inspect') and names the concrete resources covered: body, Point and Box controls, joints, and finger controller candidates. This makes it distinguishable from generic sibling tools like cascadeur_list_objects or cascadeur_get_object, 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?

No guidance is provided about when to choose this tool over alternatives such as cascadeur_list_objects, cascadeur_get_object, or cascadeur_get_state. The verb 'Inspect' implies a read-only use case, but there are no exclusions, prerequisites, or alternative-routing hints.

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 goes beyond the annotations by explicitly warning 'Dispatch is not verified success' and noting that many actions are toggles or depend on selection/license. This is valuable behavioral disclosure that the destructiveHint annotation alone does not convey, and it 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 two sentences with the core purpose front-loaded in the first sentence and important caveats in the second. There is no filler, and every word adds value for an agent deciding whether and how to call this 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?

For a 2-parameter, no-output-schema tool with destructiveHint, the description covers the essential purpose, parameter roles, and behavioral caveats. It leaves out specific error handling or result interpretation, but the 'not verified success' note covers the main risk. Slightly more detail on how to determine success could elevate it, but it is 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?

With 0% schema description coverage, the description compensates by linking 'name' to actions from list_actions and 'expected_scene' to an explicitly named scene. It does not specify exact formats or where to find scene names, but the mapping is enough to make both parameters meaningful beyond their bare 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 states a specific verb ('Dispatch'), a resource ('a named action from list_actions'), and a target ('an explicitly named scene'). It clearly distinguishes this from the sibling cascadeur_list_actions, which lists actions rather than runs them, and gives enough clarity that an agent knows exactly what the tool does.

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

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

The description provides solid usage context: actions come from list_actions, and many are toggles or depend on selection/license, signaling when care is needed. It does not explicitly name exclusions or alternatives, but the reference to list_actions and the caveats give clear situational guidance without needing an explicit when-not.

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 the tool read-only, idempotent, and non-destructive. The description adds useful context by indicating the analysis is global and quantitative rather than a subjective quality metric, but it does not disclose potential costs, output magnitude, or any other behavioral caveats.

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

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

Two short sentences with no filler; the core purpose is front-loaded and the usage caveat is a useful second sentence. 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 high-level output categories are stated, and read-only annotations cover safety behavior, so the tool is recognizable and scoped. However, with no output schema and no parameter definitions, an agent still lacks enough detail to know exactly what values to pass or what shape to expect back.

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

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

With 0% schema description coverage, the description needed to explain objects, first, last, and step, but it does not mention any of them. Parameter meanings are only inferable from their names and types, and step semantics are ambiguous (sampling interval vs. output metric).

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 action and resource ('sample global trajectories, path lengths and maximum step distances') and adds a clear disclaimer that it is not an artistic quality score. It is unambiguous about the tool's purpose, though it does not explicitly differentiate itself from sibling tools by name.

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 states when the tool is appropriate ('useful for drift/jumps') and explicitly rules out a common misuse ('not an artistic quality score'). It does not name an alternative tool, but the when/when-not guidance 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 mark the tool as destructive and non-read-only, and the description adds the key behavioral rule that overwrite=true is required to replace an existing file. It clarifies the controlled destructive condition but does not state what happens when overwrite is false and the file already exists, nor whether the save is atomic or returns an error.

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

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

One sentence of 16 words with no filler. The main purpose is front-loaded, and the overwrite caveat follows naturally. Every part of the 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 file-saving tool, the description covers the workspace constraint and the overwrite requirement, but it omits path-format details and failure behavior when overwrite=false with an existing file. Without an output schema or param descriptions, this leaves an agent needing to guess important calling conventions.

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 carry parameter meaning. It does explain the behavioral effect of overwrite=true, which adds real semantics over the bare boolean schema. However, it gives no guidance for the required path parameter, such as whether paths are workspace-relative, whether the .casc extension must be included, or whether intermediate directories are created.

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

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

The description states a specific action and resource: saving a .casc checkpoint inside the workspace. This clearly distinguishes the tool from siblings like cascadeur_export_fbx and cascadeur_open_scene, which have different file/resource targets. The scope 'inside the workspace' and the .casc format make the purpose unambiguous.

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

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

The description provides one usage constraint (overwrite=true is required to replace an existing file), but gives no guidance on when to choose this tool over alternatives like export_fbx, or what prerequisites exist (e.g., an active/current scene). It does not mention 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, so the agent is warned of mutating behavior. The description adds a temporal precondition but does not disclose what state changes occur (e.g., overwriting previous selection, clearing selections) or what exactly becomes destructive. 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?

A single sentence that is front-loaded with the main action and includes the relevant usage context. No redundant words or padding, 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?

The tool has three required parameters with zero schema descriptions and no output schema, so the description must provide enough context to invoke it correctly. It fails to clarify essential parameter semantics and side effects, leaving an agent to guess at the meaning of 'first' and 'last.' The usage context alone is not enough for safe and correct use.

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 lack of parameter documentation. It only implies 'track interval' without explaining that 'tracks' specifies which tracks, or whether 'first' and 'last' are frame indices, inclusive/exclusive, or require ordering. This is insufficient for correct parameter filling.

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 identifies a specific verb and resource ('Select an explicit track interval') and states its intended context ('before physics, mirror, clipboard or timeline actions'). This differentiates it from sibling tools like cascadeur_select_objects or cascadeur_set_frame, though it doesn't fully define what a 'track interval' is.

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

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

The description gives clear contextual guidance by saying the selection should happen 'before physics, mirror, clipboard or timeline actions,' indicating when it should be used. However, it does not mention alternative tools or any when-not-to-use conditions, so it falls 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?

The destructiveHint annotation already signals mutation, and the description adds the useful behavior that an empty list clears the current selection. It does not contradict annotations, but it does not explain replacement semantics, error behavior, or how selection affects later actions.

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

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

Two short sentences with no filler. The primary action is front-loaded, and the empty-list behavior is a valuable second sentence.

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

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

For a one-parameter selection tool with no output schema, the description covers the essential invocation details: pass exact objects to select, pass an empty list to clear. It does not mention how to discover valid object names, but the sibling cascadeur_list_objects exists for that purpose.

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 compensate. It adds meaning by stating that an empty list clears the selection, and 'exact objects' hints that strings are object identifiers. It does not specify the identifier format, case sensitivity, or behavior for invalid 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 uses a specific verb ('Select') and resource ('objects'), and clarifies the selection is exact. It is distinguishable from the sibling cascadeur_select_frames, which operates on frames, and from list/get object 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 phrase 'for context-sensitive actions' indicates when the tool is useful, and 'An empty list clears selection' gives a concrete usage rule. However, it does not explicitly name alternatives or state when not to use it, leaving 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 indicate destructiveHint=true, but the description adds no context about what changes are made, whether the previous camera position is lost, or any side effects. It only clarifies the unit system ('scene units'), which is useful but insufficient for a 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 a single concise sentence with no redundant words. It front-loads the verb and resource, and every phrase ('active viewport', 'position/target', 'scene units') adds meaningful 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 2-parameter tool with no output schema and no parameter descriptions, the description is too sparse. It omits key context such as optionality semantics, the distinction between position and target, and any behavioral caveats from the destructive 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 schema has zero description coverage, leaving the meaning of 'position' vs 'target' and the null defaults unexplained. The description mentions both fields and scene units, but does not clarify how the two camera parameters relate (e.g., camera origin vs look-at point) or what passing null does.

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 ('Set'), a specific resource ('active viewport camera'), and the specific data being modified ('position/target') plus units. This clearly distinguishes it from sibling tools like cascadeur_get_camera and cascadeur_set_view_mode.

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 cascadeur_get_camera or cascadeur_set_view_mode. The description only states what it does, not when it is the appropriate choice or any prerequisites like requiring an active scene or 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?

The description adds valuable behavioral context beyond the annotations: it warns that Cascadeur can clamp the requested frame and instructs the agent to read the returned frame. This is a non-obvious behavior that prevents the agent from assuming the requested frame was applied exactly. No contradiction with the destructiveHint=true 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 exceptionally concise: two short sentences totaling 14 words. The purpose is front-loaded in the first sentence, and the second sentence adds an essential behavioral caveat. There is no filler or redundant 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 tool with a single parameter, no output schema, and existing annotations, the description covers the essential points: what it does, what to pass, and a critical behavioral warning about clamping. It could mention whether the operation is undoable or what happens if the scene has no timeline, but for a simple timeline-cursor setter the description is reasonably 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 0% schema description coverage, the description carries the full burden of parameter explanation. It does not explicitly explain that the 'frame' parameter is the target timeline position, although this is implied by 'Move the timeline cursor.' There is no discussion of units, valid ranges beyond schema min/max, or how clamping relates to the parameter. The description adds minimal meaning beyond the parameter's self-evident name.

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: 'Move the timeline cursor.' This clearly distinguishes it from siblings like cascadeur_set_range or cascadeur_select_frames, which operate on ranges or selections. It could name an alternative explicitly, but the action 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 usage through the tool name and action, but it does not explicitly state when to use this tool versus alternatives like set_range or select_frames. It does provide a practical usage tip—'Read the returned frame because Cascadeur can clamp it'—which guides invocation, but this is not the same as context for choosing the 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?

Annotations already mark the tool as destructive (destructiveHint: true), so the description adds value by warning that changing interpolation can affect overshoot and intermediate poses. This gives the agent a concrete expectation of visual or pose-level side effects beyond the annotation.

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

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

Two short sentences, with the core action front-loaded and a safety-oriented verification note after. Every word adds value and there is no filler.

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

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

For a simple 3-parameter mutation tool with no output schema, the description is minimally adequate: it states the action, the constraint that keys must already exist, and a verification step. It omits details like behavior when keys are missing, return values, or error cases, but the destructive hint and verification advice cover the most important 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?

With 0% schema description coverage, the description carries the full burden for parameter meaning. It maps 'interpolation' to outgoing interpolation and hints at 'existing keys' for frames, but it does not explain what 'tracks' refers to or clarify the relationship between tracks, frames, and existing keys. The description only partially compensates for the schema gap.

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

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

The description uses a specific verb and resource: 'Set outgoing interpolation at existing keys.' This clearly distinguishes it from sibling tools like cascadeur_set_keys, which likely sets key values rather than interpolation modes.

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 'at existing keys' provides clear context that this tool modifies already-created keys rather than creating new ones. The follow-up instruction to 'Verify overshoot and intermediate poses' gives practical usage guidance. However, it does not explicitly name alternatives or say when not to use this 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?

Annotations already signal that the tool is destructive and not read-only, so the description does not need to restate that. It does add the useful constraint that keys are set only on 'explicit unlocked tracks', which is behavior beyond what annotations provide. However, it does not explain failure modes or whether existing key data is overwritten.

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 filler and the core action is front-loaded. The phrase 'allocate animation data' is slightly obscure, but overall the structure is efficient and clear enough for domain users.

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 there is no output schema, no parameter descriptions, and a destructive mutation tool with three parameters, the description is too thin. It does not explain frames, interpolation, prerequisites, or side effects, leaving an agent under-informed for reliable invocation.

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

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

Schema description coverage is 0%, so the description carries the burden for parameter meaning. It references 'tracks' but does not explain what the frames array represents, what the interpolation enum controls, or how the parameters interact. This is only a partial compensation for the missing 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 specific verb and resource: 'Add or update keys' on tracks, which clearly distinguishes it from siblings like cascadeur_remove_keys and cascadeur_set_interpolation. The qualifier 'on explicit unlocked tracks' adds useful scope, though 'allocate animation data' is somewhat vague.

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 cascadeur_set_pose, cascadeur_animate_transforms, or cascadeur_set_interpolation. The phrase 'explicit unlocked tracks' implies an eligibility condition but does not clarify when an agent should choose this tool over related ones.

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 need not repeat that. It adds meaningful behavioral context: position units, delta rotation degrees, and the important caveat that rig solving can adjust values. This goes beyond the structured 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 a single, information-dense sentence with no filler. It front-loads the primary purpose and follows with two essential caveats, making every word valuable.

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

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

For a tool with three top-level parameters and a nested Transform object, the description omits critical operational details such as what frame and interpolation do, how multiple transforms are applied, and the meaning of reference_frame. The no-output-schema condition further increases the need for explanation, which 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 description coverage is 0%, so the description must compensate, but it only clarifies units for position and delta rotation. It does not explain frame, transforms structure, interpolation, rotation_quaternion_wxyz, space, or reference_frame, leaving significant gaps.

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 ('Key') and resource ('body or finger controls'), making the tool's function clear. It also implies the action is a pose-setting operation, distinguishing it from sibling tools like get_pose or mirror.

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 such as cascadeur_set_keys, cascadeur_animate_transforms, or cascadeur_set_properties. There are no explicit conditions, exclusions, or references to sibling tools.

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

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

The annotations already mark the tool destructiveHint=true; the description adds beyond that by warning that editing channels can change rig/physics behavior. It also implies a low-level mutation rather than simple keyframe editing. 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?

Three short sentences: core action, risk warning, prerequisite. Each sentence adds distinct information and the most important guidance is front-loaded. There is no filler or repetition of schema details.

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, low-level setter with no output schema, the description covers the essential behavior, the advanced risk, and the required discovery step. It omits examples and does not specify how frame relates to channel edits, but that is largely recoverable from the schema and the clear prerequisite.

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 compensate. It indirectly explains object/name/value semantics via 'discovered data channels' and 'no guessed names', and scalar/vector hints value shapes. However, it does not explain the required frame parameter or the structure of properties beyond that, so the compensation is only partial.

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+resource: 'Edit discovered scalar/vector data channels'. It also signals scope by warning not to guess names and to read get_object first, which helps distinguish this low-level channel editor from pose/animation tools like cascadeur_set_pose and cascadeur_set_keys, though it does not name those siblings 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?

It gives a concrete prerequisite and operating rule: 'Read get_object first; no guessed names.' This tells the agent how to prepare and when the operation is valid, and the 'Advanced' warning flags it as not a routine pose edit. It does not list explicit alternatives/exclusions, but the context is clear enough.

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 mutation is clear. The description adds one useful behavioral clarification: it doesn't allocate animation data or add keyframes. This adds context beyond the annotations, but it doesn't describe other behavioral effects like overwriting existing boundaries or affecting the active 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?

Two short sentences, front-loaded with the main action and a clarifying non-effect. Every phrase earns its place with no superfluous 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-integer setter, the description is mostly complete: it states the purpose and clarifies what it doesn't do. Minor gaps remain, such as whether the range applies to the active scene, action, or playback context, but the low complexity plus annotations make this reasonably 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?

Schema description coverage is 0%, so the description must compensate. 'Playback boundaries' gives contextual meaning that first and last are boundary frame numbers, which helps map the two integer parameters to the tool's purpose. However, it doesn't explain ordering requirements, inclusivity, or how values relate to the animation timeline.

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 core action clearly: 'Set playback boundaries.' This identifies the specific resource being modified and is appropriately scoped. The second sentence helps distinguish it from animation/keyframe tools, though it doesn't explicitly name the sibling alternatives.

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

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

The description gives some implied usage guidance by stating what it does not do ('does not allocate animation data or add keyframes'), which helps prevent misuse for keyframe creation. However, it doesn't explicitly state when to prefer this over related tools like cascadeur_set_frame or cascadeur_select_frames.

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 tool can alter state. The description adds contextual value by scoping the effect to the active viewport and framing the change as a display mode. However, it does not disclose what exactly gets changed or whether existing viewport settings are reset, leaving the destructive implications partly unexplained.

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 filler. Every word contributes meaning by naming the two display categories and the scope (active viewport). It is appropriately sized for a simple one-parameter tool.

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

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

For a tool with one enum parameter and no output schema, the description gives the core action and target but is incomplete on the meaning of the modes. Since destructiveHint is set, the agent would benefit from at least a note on side effects. The description is workable for a domain-expert agent but leaves ambiguity that the schema cannot resolve.

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 one parameter with a 6-value enum and 0% description coverage, so the description must carry the semantics. It vaguely groups the modes into 'clean mesh review' and 'rig controller display mode', but it does not map the enum values (View, AutoPosing, PointController, Controller, Joint, Mesh) to those categories. This leaves several ambiguous modes, like PointController vs Controller, 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 clearly states a specific action: choosing a mesh review or rig controller display mode for the active viewport. It identifies the resource (viewport) and the verb (choose/set). However, it does not explicitly differentiate from sibling tools like cascadeur_set_camera or cascadeur_set_properties, which could also affect viewport display.

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 only says the tool targets the active viewport, but it provides no guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. For example, it does not mention that setting a view mode affects only the active viewport and not the scene state, or when a different tool like set_camera would be more appropriate.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds the explicit guarantee of not changing the scene, which is consistent, but it does not add other behavioral context such as authentication requirements, failure modes, or whether a workspace must be active. With strong annotation coverage, the description does not go beyond annotations significantly.

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 gives the complete what and why. Every word earns its place: the verb, the resources checked, and the non-mutating guarantee. No filler or redundancy.

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

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

For a zero-parameter inspection tool, the description is sufficient to understand what will be checked and that no scene changes will occur. Since there is no output schema, a tiny bit more detail about what the response contains could be useful, but it is not essential for selecting or invoking the tool correctly.

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

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

The tool has zero parameters, so the input schema carries no burden and the baseline is 4. The description appropriately says nothing about parameters because there are none to document.

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 ('Check') and a concrete set of resources: app heartbeat, workspace, bridge version, and scripting opt-in. It clearly distinguishes from scene-mutating tools by stating it does not change the scene, but it does not explicitly distinguish it from similar inspection siblings like cascadeur_get_state or cascadeur_capabilities.

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 'without changing the scene' implies this is the safe, read-only status check to use when you only need environment/connectivity information. However, it gives no explicit guidance about when to prefer this over the various other inspection tools in the sibling list, so the usage context is only implied.

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