imgui_bind

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 does disclose the per-frame continuous behavior ('Each frame the source widget's property is read, scaled, offset, and written to the target'), which is valuable side-effect transparency. However, it doesn't disclose what imgui_unbind does to reverse this, lifetime/cleanup semantics, or whether creating a new bind overwrites an existing one.

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?

Two sentences, efficient and front-loaded. The 'each frame' behavior is stated early. The example adds practical value. Could be slightly tighter but it earns its space with the operational detail and example.

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?

For an 8-parameter tool with no annotations and no output schema, the description covers the core mechanic (per-frame binding) and gives one example, but doesn't address compatibility between source_property and target_property, what happens on repeated binds for the same target, or how to break a bind. Reasonable but leaves operational edge-cases undocumented.

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 100%, so all 8 parameters are documented in the schema. The description adds minimal param value: it illustrates the scale/offset flow and gives a binding example, but doesn't clarify ambiguities like which target_property values pair with draw_layer vs hit_region vs widget targets, or whether source_property and target_property must be compatible types.

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 verb 'Bind' with a specific resource (widget values to visual properties). It explains the operational flow (read, scale, offset, write) and provides a concrete example (slider value to draw layer opacity). This distinguishes it well from siblings like imgui_animate and imgui_unbind.

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 the general use case (binding widget values to visual properties) and an example, but doesn't explicitly state when NOT to use it versus alternatives like imgui_animate, imgui_set_callback, or imgui_update_widget. No exclusions or comparison to sibling tools for similar binding use-cases.

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