blender_set_camera

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

Beyond the annotations (readOnly=false, idempotent=true, destructive=false), the description adds meaningful behavioral context: it creates a new camera when no active scene camera exists, uses the active camera if name is omitted, and optionally aims the camera at a target. It also notes the return JSON structure. Some edge cases (e.g., behavior when a named camera does not exist) are not addressed, but the provided details are substantive and consistent 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 efficiently organized: opening purpose, fallback behavior, Args section, Returns section, and a concise example. Every sentence contributes useful information without redundancy or fluff. The front-loading of the main action ensures the agent immediately understands what the tool does.

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

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

Given the tool's moderate complexity, the description is complete: it explains the main operation, the fallback/creation behavior, the return format, and provides a concrete example. The output schema is also present, further reducing ambiguity. This description enables confident use even without prior familiarity with the tool or its siblings.

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

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

Although schema description coverage is reported at 0% for the top-level params, the description fully compensates by enumerating all parameters (name, location, target, lens, set_active) and explaining their meanings in context. The example call (location=(5,-5,3), target=(0,0,0), lens=50) demonstrates usage syntax and parameter interactions, adding value beyond the nested property 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 opening line, 'Configure a camera's position, aim target, and focal length,' uses a specific verb and resource with precise attributes, clearly distinguishing it from sibling tools like blender_transform_object or blender_get_object_info. It further clarifies scope with fallback behavior ('Uses the active scene camera if no name is given') and creation behavior ('Creates a new camera if the scene has none').

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 strongly implies its usage context through the operation it performs and the fallback behaviors, but it does not explicitly name alternatives or state when not to use it. The guidance is clear enough for an agent to select it for camera configuration, yet lacks the explicit 'when-to-use vs. alternative' contrast seen in top-tier descriptions.

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