calculate_blend_space_2d

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 says 'Compute and inject', implying a mutation, but does not disclose whether the scene file is modified in-place, whether it creates or updates an existing node, what happens if the scene is missing or the node name conflicts, or any side effects on existing blend spaces. There is no mention of reversibility, permissions, or error behavior. This is a significant gap for a tool that modifies scene files.

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

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

The description is well-structured and front-loaded: the purpose is stated first, followed by blend point requirements, then an Args list. It is concise, with no filler sentences. The Args section is formatted for readability. It earns a 4 for efficiency and clarity of structure.

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

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

The tool is complex: it injects an AnimationNodeBlendSpace2D into a scene file, requiring prerequisites like an existing scene file, AnimationPlayer, and animation clips. The description does not mention these prerequisites, side effects, or what happens on invalid inputs. It also does not state whether it replaces an existing blend space or how it integrates with the AnimationTree. With no annotations and no output schema shown, the description is incomplete for safe usage.

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

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

Schema description coverage is 0%, so the description must compensate. It explains the structure of blend_points in detail (animation and position fields with examples), and gives a one-line description for each parameter in the Args section. However, it does not explain the semantics of node_name (e.g., whether it replaces an existing node), the expected format of scene_path, or the meaning of axis labels beyond being labels. It adds value over the bare schema but does not fully compensate for the lack of schema descriptions on all 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 states a specific verb ('Compute and inject'), a specific resource (AnimationNodeBlendSpace2D), and the use case (directional locomotion blending N/S/E/W + idle). This clearly distinguishes it from sibling tools like generate_state_machine or compile_state_transitions, which target different animation structures. The purpose is unambiguous.

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

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

The description implies usage for directional locomotion blending, but it does not explicitly state when to choose this tool over alternatives or list exclusions. There is no mention of when not to use it, such as for state machines or other blend types. The context is inferable from the description, but not made explicit, so it earns a 3.

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