flexsim_set_view

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

No annotations are provided, so the description carries the full burden, and it does so well: it discloses the absence of a verified camera API, that the tool 'can neither hang nor move the model', that the view is only recorded as intent, and that screenshot cropping uses fixed fractions tuned for the default template. It stops short of describing the exact response content, which is partly covered by the output schema.

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 headline is front-loaded, but the body rambles across implementation details (utility/capture.py:131, VIEW3D_CROP fractions) and repeated disclaimers about the screenshot tool for what is a two-field tool. Much of the second paragraph does not help an agent invoke 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?

With an output schema present, return values need not be described, and the description covers the key behavioral caveats (no real camera control, safe/non-hanging, intent recording). For a low-complexity tool it is largely complete, though the misleading framing leaves some ambiguity about what an agent actually gains from calling 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?

Schema description coverage is 0%, so the description must compensate. It explains target (object name or 'all', default) and view (3d/top/front) and, crucially, reveals that view is only recorded intent rather than an actual camera change – meaning beyond what the enum pattern in the schema conveys.

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 headline verb 'Frame the 3D view on an object' is misleading, since the body immediately says the tool does NOT touch the camera and only verifies the target, reports position, records intent, and runs repaintall(). Once read fully, the actual behavior is specific (Model.find verification, repaintall, screenshot handoff) and it names the sibling alternatives, but the name/headline overpromises relative to what it 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?

It routes the agent explicitly: for target='all' use flexsim_inspect_model + flexsim_layout_line, and to frame by hand use the view cube / View menu. It also tells the agent to confirm with flexsim_screenshot. Clear context, though it never states a clean 'use this when X' condition for the tool itself.

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