Server Quality Checklist

Tool Scores

• cavalry_delete_layerC
  2.9/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden. It only says 'Deletes', which implies mutation, but does not disclose whether deletion is permanent, reversible, or affects child elements. For a destructive operation, this is insufficient.

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

  Conciseness4/5

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

  The description is a single sentence with no wasted words. It is concise but could be more informative. It is appropriately front-loaded, though slightly too terse for a destructive tool.

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

  Completeness3/5

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

  Given the tool's simplicity (one parameter, no output schema, no annotations), the description is functionally complete. However, it lacks behavioral context such as side effects, permanence, or error states, which would be valuable for a delete operation.

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

  Parameters3/5

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

  Schema coverage is 100% and the parameter description already explains 'The ID of the layer to remove'. The description adds no additional meaning beyond that. Baseline 3 is appropriate as the schema does the heavy lifting.

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

  Purpose4/5

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

  The description clearly states the verb 'Deletes' and the resource 'layer or node from the scene'. It distinguishes from sibling tools like create, get, or set attributes. However, 'node' is ambiguous as the parameter is specifically 'layerId', causing slight confusion.

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

  Usage Guidelines2/5

  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. There is no mention of prerequisites, such as the layer needing to exist, or conditions for deletion. The description is purely declarative.

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

• cavalry_disconnect_attributesB
  3.1/5.0
  Behavior2/5

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

  With no annotations, the description must convey behavioral traits. It only states that it 'breaks a connection' but does not disclose whether the operation is reversible, what happens if the connection does not exist, or any side effects. Essential behavioral context is missing.

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

  Conciseness4/5

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

  The description is a single sentence of 13 words, efficiently front-loaded and without any wasted words. However, it may be considered too brief for the tool's complexity.

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

  Completeness2/5

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

  Given the tool has 4 parameters (2 required), no output schema, and no annotations, the description is insufficient. It does not explain return values, error conditions, or the fact that this is a mutation operation. The brevity leaves major gaps for an agent to use the tool correctly.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the input schema already provides clear meanings for each parameter. The description does not add any extra semantics beyond what the schema offers, resulting in a baseline score of 3.

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

  Purpose5/5

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

  The description uses a specific verb 'breaks' and clearly identifies the resource 'connection to a specific attribute on a target node'. It distinguishes itself from the sibling tool 'cavalry_connect_attributes' which does the opposite operation.

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

  Usage Guidelines2/5

  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 'cavalry_connect_attributes' or 'cavalry_set_attributes'. There is no mention of prerequisites, context, or 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.

• cavalry_get_selected_layersB
  3.1/5.0
  Behavior2/5

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

  No annotations are available, so the description carries the full burden of behavioral disclosure. It states it returns an array of IDs, but does not indicate whether it is a read-only operation, what happens when nothing is selected, or any side effects. The simplicity suggests safety, but transparency is insufficient.

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

  Conciseness5/5

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

  The description is a single sentence that is front-loaded with the core action and resource. Every word is necessary; no fluff or repetition. It is optimally concise for the purpose.

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

  Completeness2/5

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

  Given the lack of annotations and output schema, the description should provide more context about return values (empty vs. multi-selection), side effects, and operational context. It only covers the basic purpose, leaving gaps that could confuse an agent deciding when to invoke this tool.

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

  Parameters4/5

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

  There are no parameters, so the input schema already covers everything. The description does not need to add parameter meaning, and it does not miss any opportunity. According to guidelines, 0 parameters warrants a baseline of 4.

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

  Purpose4/5

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

  The description clearly states the action ('returns an array of IDs') and the resource ('currently selected layers in the Cavalry viewport / scene tree'). It implicitly differentiates from sibling `cavalry_get_comp_layers` by specifying 'selected' layers, but does not explicitly contrast with other getters.

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

  Usage Guidelines2/5

  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 `cavalry_get_comp_layers` or when not to use it. The description only states what it does, leaving the agent to infer appropriate usage without exclusions or prerequisites.

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

• cavalry_get_attributesB
  3.2/5.0
  Behavior2/5

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

  No annotations are provided, so the description fully carries the burden of behavioral disclosure. It only says 'Retrieves', implying a read operation, but does not mention whether the tool is read-only, if it requires any permissions, what happens if the layer doesn't exist, or if it supports batch queries. The lack of depth leaves significant behavioral ambiguity.

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

  Conciseness4/5

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

  The description is a single sentence, efficient and front-loaded with the core action. It conveys the essential purpose without extraneous detail, earning its place.

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

  Completeness3/5

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

  Given the low complexity (2 params, no nested objects, no output schema), the description is adequate but not thorough. It lacks details on error behavior (e.g., invalid path) or return format, which would be helpful.

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

  Parameters3/5

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

  Schema description coverage is 100%, so baseline is 3. The description adds minimal value by mentioning 'value of a specific attribute or array of attributes', which hints that attributePath can be singular or complex, but does not elaborate on the format or examples beyond what the schema already documents.

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

  Purpose4/5

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

  The description clearly states the tool retrieves attribute values from a layer using a specific verb ('Retrieves') and resource ('attribute' of 'layer'). It is distinct from siblings like 'cavalry_set_attributes' which sets values, and 'cavalry_get_comp_layers' which lists layers, so purpose is clear with implicit differentiation.

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

  Usage Guidelines3/5

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

  The description implies usage for reading attributes but provides no explicit guidance on when to use this vs alternatives like 'cavalry_eval_expression' (which could also retrieve computed values) or 'cavalry_get_comp_layers' (which returns layer info but not attributes). No when-not or prerequisite context is given.

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

• cavalry_get_comp_layersB
  3.2/5.0
  Behavior2/5

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

  The description only states the return type without disclosing behavioral traits. Since no annotations are provided, the description carries full burden. It does not mention that the operation is read-only, any dependencies on composition state, or potential side effects. The agent lacks information about performance or error conditions.

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

  Conciseness5/5

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

  The description is a single, focused sentence with no wasted words. It is front-loaded with the key action and result, achieving maximum conciseness.

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

  Completeness2/5

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

  Given the absence of an output schema, the description should explain the structure of the returned array (e.g., string IDs or objects). It also lacks context about the 'active composition' concept and error handling. For a simple tool with one parameter, the description is insufficient for an agent to fully understand the tool's behavior.

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

  Parameters3/5

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

  The input schema has 100% description coverage, with a clear explanation for the single parameter 'topLevelOnly'. The tool description adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states the verb 'Returns' and the resource 'array of layer and node IDs present in the active composition'. It distinguishes this tool from siblings like 'cavalry_get_selected_layers' (selected layers) and 'cavalry_get_scene_info' (scene info), providing a specific scope.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives such as 'cavalry_get_selected_layers' or 'cavalry_get_scene_info'. There is no mention of filter conditions, prerequisites, or when the 'topLevelOnly' parameter is appropriate.

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

• cavalry_eval_expressionB
  3.3/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It states that it evaluates an expression and returns its value, but it does not disclose potential side effects, whether the evaluation is read-only, or if the expression can modify state. Given that evaluating arbitrary JavaScript could have side effects, this lack of transparency is a significant gap.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence that efficiently conveys the core purpose. There is no unnecessary verbosity or repetition. Every word contributes to clarity, making it optimally concise.

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

  Completeness3/5

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

  Given the simplicity of the tool (one param, no output schema) and lack of annotations, the description is adequate but not thorough. It mentions that it returns a value but does not specify the nature of that value (e.g., types, serialization) or note that evaluation occurs within a specific Cavalry context. It could be more explicit about side effects or limitations, but for a basic evaluation tool, it is reasonably complete.

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

  Parameters3/5

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

  The input schema fully describes the single parameter 'expression' with a clear description and examples. The tool description adds no extra detail about the parameter beyond what the schema already provides. Since schema coverage is 100%, the baseline of 3 applies, and the description does not meaningfully enhance the parameter semantics.

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

  Purpose5/5

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

  The description clearly states the tool's function: evaluating a single JavaScript expression inside Cavalry and returning its value. The verb 'Evaluates' is specific, the resource is well-defined, and it distinguishes from siblings like cavalry_run_script which runs scripts or cavalry_get_comp_layers which retrieves layers.

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

  Usage Guidelines2/5

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

  The description gives no explicit guidance on when to use this tool versus alternatives. It doesn't mention scenarios where running a full script via cavalry_run_script would be more appropriate, nor does it provide any exclusions or prerequisites. The usage context is only implied by the word 'single' versus a script.

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

• cavalry_add_to_render_queueB
  3.4/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full burden. It briefly states that the tool adds to the render queue, implying a mutation, but it does not disclose whether the action is reversible, what happens if the composition is already queued, or if any permissions are needed. It adds basic context but leaves gaps for a mutation tool without annotations.

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

  Conciseness4/5

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

  The description is a single, concise sentence that communicates the core function and key parameters. It is front-loaded and contains no extraneous words. It earns its place, though it could be slightly more descriptive without becoming verbose.

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

  Completeness3/5

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

  Given the tool has only 2 parameters, 100% schema coverage, and no output schema, the description adequately covers the primary action. However, it omits important context such as whether the tool assumes the composition is already loaded or what the return value (if any) indicates about success. More detail on preconditions or error states would improve completeness.

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

  Parameters3/5

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

  Schema coverage is 100%, so the schema already documents both parameters. The description mentions 'format or destination', which maps to the two parameters but does not add deeper meaning (e.g., default behavior when outputPath is omitted, or supported format details beyond the enum list). Baseline 3 is appropriate since schema does the heavy lifting.

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

  Purpose4/5

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

  The description uses a specific verb ('Adds') and clearly identifies the resource ('active composition' and 'Cavalry Render Queue'). It also mentions the configurable options ('format or destination'), which helps distinguish it from sibling tools like cavalry_render_queue or cavalry_run_script. However, it does not explicitly contrast with those siblings, and 'active composition' could be clarified further.

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

  Usage Guidelines3/5

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

  The description implies when to use the tool (when you want to queue a render), but it provides no guidance on when not to use it or which sibling tool to choose instead. For example, it doesn't mention that cavalry_render_queue might be for managing the queue itself. This leaves the agent to infer usage context.

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

• cavalry_create_primitiveB
  3.4/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It conveys that the tool creates a shape and accepts optional attributes, but does not disclose side effects (e.g., whether it appends to the current composition, whether it is destructive, or what happens to existing layers). The behavioral transparency is adequate but not thorough.

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

  Conciseness4/5

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

  The description is a single sentence that front-loads the core purpose and includes specific examples. It is concise and efficient, though a more structured format (e.g., breaking out parameters or usage notes) could improve readability.

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

  Completeness3/5

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

  For a simple creation tool with three parameters, the description covers the main action and examples. However, there is no output schema and the description does not hint at the return value or confirmation of creation, leaving the agent uninformed about what to expect after invocation.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents all parameter roles. The description provides examples of attribute keys and values, which adds marginal value over the schema's example. No additional semantics like constraints or edge cases are provided.

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

  Purpose5/5

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

  The description clearly states the tool creates a geometric primitive shape in Cavalry, listing specific types (e.g., ellipse, rectangle) and optional initial attributes. It effectively distinguishes from siblings like cavalry_create_layer by specifying 'geometric primitive'.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives such as cavalry_create_layer (which may create other layer types). There are no prerequisites, exclusions, or context about when it is appropriate to invoke this tool.

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

• cavalry_set_attributesB
  3.4/5.0
  Behavior2/5

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

  No annotations are present, so the description carries the full burden. It only states that the tool 'sets' attribute values, but does not disclose whether this is a destructive or additive operation, whether the values are validated, what happens if the layer ID is invalid, or if there are any side effects. For a mutation tool, this is insufficient.

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

  Conciseness5/5

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

  The description is a single, well-structured sentence that immediately conveys the core functionality. It includes concrete examples, making it easy to understand without any wasted words.

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

  Completeness2/5

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

  Given the tool modifies state, has no output schema, and no annotations, the description should cover error conditions, behavior on invalid inputs, and whether the changes are reversible. It only covers the basic action, leaving significant gaps in the agent's understanding of how to use it safely.

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

  Parameters3/5

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

  Schema coverage is 100%, so the baseline is 3. The description adds example attribute paths and values, which complements the schema's key-value map description. However, it does not explain the format of attribute paths in depth or any constraints on values, so the added value is modest.

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

  Purpose5/5

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

  The description clearly states the action ('Sets one or more attribute values'), the resource ('an existing layer in Cavalry'), and provides specific examples of attribute paths like 'material.materialColor' and 'position.x'. This distinguishes it from siblings like cavalry_get_attributes or cavalry_set_keyframe, which have different purposes.

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

  Usage Guidelines3/5

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

  The description implies the tool is for modifying existing layers, but it does not explicitly state when to use this tool versus alternatives such as cavalry_set_keyframe (for keyframing) or cavalry_eval_expression (for computed values). No guidance on prerequisites or exclusions is provided.

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

• cavalry_playback_controlA
  3.5/5.0
  Behavior3/5

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

  The description discloses that the tool operates on the 'active viewport', which is a useful behavioral constraint beyond the input schema. However, with no annotations provided, it does not disclose whether the tool is destructive (e.g., rewind could reset state), has side effects on UI state, or requires specific permissions. The description is adequate but lacks depth for a control tool.

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

  Conciseness5/5

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

  The description is a single, short sentence that front-loads the purpose and scope. Every word earns its place with no redundancy or filler.

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

  Completeness3/5

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

  Given the tool's simplicity (1 parameter, no output schema), the description is mostly complete for basic use. However, it lacks details on return value (e.g., does it return success?), prerequisites (viewport must be active), or behavior edge cases (e.g., what happens if playback is already stopped?). The absence of annotations further limits completeness.

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

  Parameters3/5

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

  Schema description coverage is 100% for the single parameter, so the baseline is 3. The description adds minimal value beyond the schema—it lists the actions but does not clarify their exact behavior (e.g., does 'rewind' go to frame 0 or a previous marker?). The enum is self-documenting, so this is acceptable.

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

  Purpose4/5

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

  The description clearly states the verb 'controls' and the resource 'timeline playback', and lists the specific actions (play, stop, rewind) and scope ('in the active viewport'). It distinguishes well from sibling tools like `cavalry_set_frame`, `cavalry_delete_layer`, or `cavalry_run_script`, which have different purposes.

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

  Usage Guidelines3/5

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

  The description implicitly indicates when to use this tool (to control playback) and the active viewport context, but it provides no explicit guidance on when not to use it or alternatives. For example, it does not mention that the viewport must be open or that the tool has no effect during rendering.

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

• cavalry_render_queueA
  3.5/5.0
  Behavior3/5

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

  With no annotations provided, the description must cover behavioral traits. It correctly indicates a triggering action (non-destructive, likely readWrite based on 'triggers'), which matches the sibling context (rendering operations). However, it does not disclose critical details like whether this is synchronous or asynchronous, what happens if the queue is empty, or if it requires a running application state. A 3 is appropriate for minimal but acceptable transparency given the zero-parameter simplicity.

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

  Conciseness5/5

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

  The description is a single sentence with no wasted words. It front-loads the action ('triggers rendering') and specifies the target ('items in the Render Manager / Render Queue'), achieving maximum clarity with minimal length. Every word is essential.

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

  Completeness4/5

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

  Given zero parameters and no output schema, the description is reasonably complete for a simple trigger tool. It explains what the tool does without needing to describe complex inputs or outputs. However, it could briefly mention behavioral aspects like whether it runs asynchronously or returns a status, which would improve completeness. The sibling tools show this is part of a rendering workflow, and the description fits that context adequately.

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

  Parameters4/5

  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% (schema is empty with no properties). The description adds value by clarifying that no additional input is needed – it operates on the existing render queue. This is sufficient for a parameterless tool, earning a 4 since the description compensates for the lack of parameter details.

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

  Purpose4/5

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

  The description clearly states the action ('triggers rendering') and the resource ('items in the Render Manager / Render Queue'), providing a direct purpose. It distinguishes from siblings like 'cavalry_add_to_render_queue' which adds items to the queue, while this tool triggers the rendering process itself. However, it lacks details on what 'rendering' means in this context (e.g., output files, progress), keeping it from a perfect 5.

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

  Usage Guidelines2/5

  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 vs alternatives like 'cavalry_add_to_render_queue' or 'cavalry_playback_control'. There is no mention of prerequisites (e.g., items must be in the queue first) or typical workflow context. It implies usage via the action verb but lacks explicit context for selection.

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

• cavalry_set_keyframeA
  3.5/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It reveals that the tool is a write operation calling an internal API, and the 'attributes' parameter accepts a dictionary with values. However, it does not disclose important behaviors such as: whether existing keyframes at that frame are overwritten, whether the tool requires an animation context to be active, whether it modifies the project irreversibly, or if there are authorization or project state requirements. For a mutation tool with no annotations, this is adequate but incomplete.

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

  Conciseness5/5

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

  The description is a single sentence that directly states the purpose and includes the underlying API for transparency. No filler words; every part earns its place. It is front-loaded with the key action and efficiently conveys what the tool does without unnecessary detail.

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

  Completeness3/5

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

  The tool has 3 required parameters with 100% schema coverage and no output schema. The description explains the action and references the API, which helps an agent understand the technical context. However, given the complexity of animation keyframing (overwriting behavior, project state dependencies), the description is somewhat thin. It does not explain how the attributes dictionary maps to Cavalry's attribute system, nor does it tell the agent what happens on success/failure. It is adequate for a straightforward tool but could be more complete.

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

  Parameters3/5

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

  Schema description coverage is 100%—all three parameters are documented in the input schema. The description does not add any additional meaning beyond the schema's existing descriptions. The description does mention the API call style, but this is redundant with the tool name and schema. A baseline of 3 is appropriate since the schema already covers the parameter semantics, and the description adds no extra clarification.

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

  Purpose4/5

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

  The description clearly states the tool sets an animation keyframe on a layer at a given frame number, and it names the specific API being called. The verb 'Sets' and the resource 'animation keyframe for attributes on a layer' are specific. Among sibling tools like cavalry_set_attributes (which sets attributes without keyframes) and cavalry_set_frame (which moves the current frame), this tool is uniquely about keyframing, but the description does not explicitly distinguish it from those siblings.

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

  Usage Guidelines3/5

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

  The description implies usage when you want to create keyframe animation, but it provides no guidance on when to use this tool versus alternatives like cavalry_set_attributes (which sets immediate values without keyframes) or cavalry_eval_expression (which might animate differently). It also does not mention prerequisites (e.g., does the layer need to exist? Must the project be loaded?). The usage context is implied but not clarified.

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

• cavalry_run_scriptA
  3.6/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It merely states execution and use cases, without mentioning error handling, idempotency, side effects (e.g., irreversible scene modifications), return value, or execution mode (synchronous/asynchronous). This is a significant gap for a powerful script execution tool.

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

  Conciseness5/5

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

  The description is two sentences, front-loaded with the core action and purpose, followed by concise use cases. No filler or redundant information. Every sentence earns its place.

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

  Completeness2/5

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

  Given the tool's complexity (executes arbitrary JavaScript) and absence of an output schema, the description lacks crucial operational details: what happens on errors, whether the script can be debugged, if it returns any status, and how it interacts with the scene state. This makes it incomplete for safe and effective agent use.

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

  Parameters3/5

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

  Schema coverage is 100% and the parameter description already explains the code format with examples (`api.create()`, etc.). The tool description adds use-case context but no new parameter semantics beyond what the schema provides. Baseline 3 per guidelines.

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

  Purpose5/5

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

  The description clearly states the tool executes a multiline JavaScript automation script using the `api.*` module, specifying complex procedural generation, node network creation, and batch updates as use cases. This distinguishes it from sibling tools like `cavalry_create_layer` or `cavalry_set_attributes`, which handle single operations.

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

  Usage Guidelines4/5

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

  The description provides explicit use cases ('Use this for complex procedural generation, node network creation, and batch updates'), which guides when to select it over simpler single-purpose sibling tools. However, it does not explicitly state when not to use it or list alternatives.

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

• cavalry_get_frameA
  3.8/5.0
  Behavior3/5

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

  With no annotations provided, the description must disclose all behavioral traits. It indicates a read operation (no side effects) but fails to mention prerequisites (active composition required) or error behavior if none exists. Adequate for simple getter but not comprehensive.

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

  Conciseness5/5

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

  Single sentence that is front-loaded with the verb and resource. No fluff. Every word earns its place.

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

  Completeness4/5

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

  Given zero parameters and no output schema, the description mostly suffices but could clarify the return type (integer vs float). The mention of 'active composition' hints at context, but no mention of error if no composition open. Nearly complete for a simple getter.

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

  Parameters4/5

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

  There are zero parameters, so the description needs no extra parameter info. Schema coverage is 100% trivially. The description adds no param meaning because none exist. Baseline 4 for 0 parameters applies.

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

  Purpose5/5

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

  The description clearly states the verb 'Returns' and resource 'current playhead frame number in the active composition,' which precisely distinguishes it from sibling tools like cavalry_set_frame and cavalry_playback_control. No ambiguity.

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

  Usage Guidelines2/5

  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 cavalry_set_frame or cavalry_playback_control. No when-not-to-use or context for optimal invocation.

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

• cavalry_get_scene_infoA
  3.8/5.0
  Behavior2/5

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

  No annotations are provided, so the description must disclose behavioral traits. It only states what the tool retrieves, but does not mention that it is a read-only operation, whether it requires an open composition, or any potential side effects. This lack of transparency is a significant gap.

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

  Conciseness5/5

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

  Single sentence that is front-loaded with the verb 'Retrieves', clearly states the object (active Cavalry composition), and lists examples efficiently. No wasted words.

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

  Completeness4/5

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

  For a parameterless tool, the description covers the key output items. However, without an output schema, the agent may benefit from knowing the exact return format (e.g., JSON object, property names). It is adequate but not exhaustive.

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

  Parameters4/5

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

  There are zero parameters, so schema coverage is 100% by default. The description adds value by listing what the metadata includes (current frame, duration, etc.), providing context beyond the empty schema. Baseline for 0 parameters is 4.

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

  Purpose5/5

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

  The description clearly states it retrieves metadata about the active Cavalry composition, listing specific items (current frame, total duration, frame rate, layer hierarchy). It distinguishes itself from sibling tools like cavalry_get_frame (specific frame) and cavalry_get_comp_layers (layer-specific).

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

  Usage Guidelines3/5

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

  The description implies usage for general composition metadata but does not explicitly state when to use this tool over siblings (e.g., cavalry_get_frame for frame only, cavalry_get_comp_layers for layers). No exclusions or alternative preconditions are mentioned.

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

• cavalry_create_layerA
  4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden. It clearly indicates a creation action (non-destructive) and specifies the active scene requirement. However, it does not disclose potential side effects like replacing existing content with same name, or any permissions needed. Still, the core behavior is transparent.

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

  Conciseness5/5

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

  The description is a single sentence that packs the verb, resource, context (active Cavalry scene), and a comprehensive list of examples. Every word serves the purpose with no redundancy.

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

  Completeness4/5

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

  Given no output schema, the description does not explain return values, but since this is a creation tool with simple side effects (layer added), the return is likely a reference or success indicator. The 3 parameters are fully covered by the schema. The active scene context is mentioned. A brief note about return value or confirmation would improve completeness slightly.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the baseline is 3. The description adds no parameter-specific information beyond what the schema already provides (e.g., types, examples). The schema itself is adequate, so the description does not need to compensate.

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

  Purpose5/5

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

  The description uses a specific verb ('Creates') and resource ('a new layer or procedural node in the active Cavalry scene') and lists example node types, which helps distinguish it from sibling tools like cavalry_create_primitive. It clearly states both the action and the target context.

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

  Usage Guidelines3/5

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

  The description implies usage for creating various layer/node types in active scenes but provides no explicit guidance on when not to use it (e.g., when to use cavalry_create_primitive instead) or any prerequisites like an open scene. The list of examples gives some context, but siblings are not mentioned.

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

• cavalry_set_frameA
  4/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the burden of behavioral disclosure. It correctly states the action is moving the playhead to a specific frame, but does not disclose whether this triggers any updates, requires the composition to be loaded, or side effects like layer refresh. The action appears safe but lacks fuller context.

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

  Conciseness5/5

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

  The description is a single sentence that efficiently conveys the entire purpose with no wasted words. It front-loads the action and resource, making it easy to scan.

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

  Completeness4/5

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

  Given the tool's simplicity (1 required parameter, no output schema, no nested objects), the description is largely complete. It covers what the tool does and the key parameter. Minor gaps like error behavior or bounds for the frame number are not critical for this straightforward command.

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

  Parameters4/5

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

  The input schema has 100% coverage with a clear description for the 'frame' parameter (0-indexed integer). The description reinforces the parameter's purpose by linking it to 'specific frame number', which adds minimal extra meaning but complements the schema well. Since coverage is high, a 3-4 is baseline; the description is concise and non-redundant.

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

  Purpose5/5

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

  The description uses a specific verb 'Moves' and resource 'timeline playhead' to a specific frame number, clearly distinguishing it from siblings like 'cavalry_get_frame' which reads the current frame. The active composition scope is explicit, aiding precise tool selection.

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

  Usage Guidelines3/5

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

  The description implies usage when the agent needs to navigate the timeline, but it does not provide explicit when-to-use or when-not-to-use guidance compared to siblings like 'cavalry_playback_control'. No exclusions or alternatives are mentioned.

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

• cavalry_connect_attributesA
  4.5/5.0
  Behavior4/5

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

  Since no annotations are provided, the description must carry the burden of behavioral disclosure. It effectively communicates the connecting behavior and the graph context, but could add details like whether connections can be chained, if overwriting an existing connection is allowed, or what happens if parameters are invalid.

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

  Conciseness5/5

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

  The description is a single, clear sentence that conveys the core purpose without any wasted words. It is front-loaded with the key verb and resource, making it easy for an agent to parse quickly.

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

  Completeness5/5

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

  Given the tool's simple wiring operation, the schema fully documents the four parameters, and there is no output schema. The description sufficiently explains the action and context within the dependency graph. No additional information about return values is needed.

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

  Parameters4/5

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

  Schema description coverage is 100% with each parameter having a descriptive comment. The description adds meaning by framing the parameters within the source/target connection model, clarifying the tool's purpose. It does not, however, add extra context beyond the schema.

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

  Purpose5/5

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

  The description clearly states the tool connects an output attribute of a source node to an input attribute of a target node in Cavalry's dependency graph. It uses a specific verb ('connects') and resource ('attribute of a source node' to 'input attribute of a target node') and distinguishes from siblings like cavalry_disconnect_attributes.

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

  Usage Guidelines4/5

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

  The description indirectly implies when to use this tool: when one needs to establish a procedural data flow between two nodes. However, it does not explicitly state when not to use it, or mention alternatives like cavalry_set_attributes for directly setting values without connections.

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