camera_manage

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

With no annotations, the description carries full burden and exceeds it: it discloses undo behavior for make_current, class-aware property handling, enum-by-name coercion, Vector2 dict coercion for zoom/offset, empty-path resolution to active camera, and op-specific semantics like 'Pass only the edges to change' and 'Reparent camera under target'. This rich behavioral detail compensates well for missing 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 well-structured with a one-line summary, a bulleted list of operations with code-formatted signatures, and a final note on call shape compatibility. It is longer than average but every section serves a purpose, and the formatting enhances scanability. Slight redundancy (e.g., repeating 'Camera2D/Camera3D' multiple times) prevents a 5.

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 multi-op dispatcher with a generic schema, making completeness heavily reliant on the description. The description covers all 8 operations, their parameters, defaults, behavioral nuances, canonical call shape, and alias handling. It provides enough context for an agent to select and invoke the correct op, even without seeing an output schema.

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

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

Schema coverage is 0%, but the description fully defines every parameter within each op signature, including defaults (e.g., name="Camera", smoothing_speed=5.0) and value constraints (e.g., drag_margins fractions [0,1]). It explains property categories for configure and optional edge arguments for set_limits_2d, making the tool usable without needing to inspect 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 clearly states the tool's scope as 'Camera2D / Camera3D authoring' and enumerates specific operations (create, configure, set_limits_2d, etc.), making the purpose unambiguous. It distinguishes itself from sibling tools like node_set_property by focusing exclusively on camera behaviors, and the verb-first op names (create, configure, follow_2d) clearly indicate 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?

The description provides explicit guidance on when NOT to use this tool, stating transforms (position, rotation, scale) should be set via node_set_property instead. It also indirectly establishes usage context by enumerating camera-specific operations, but does not offer broader 'when to use this vs. other tools' advice beyond that one exclusion.

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