imgui_press_key

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 discloses the key behavioral trait (simulates press AND release, i.e., no hold state) which is useful. However, it doesn't describe edge behaviors like what happens with unknown keys, whether the key is sent to the focused widget, or any timing/wait implications. Decent but not comprehensive for a no-annotation tool.

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 concise sentences that capture the essence: what it does, what it supports, and concrete examples. Zero filler or redundant phrasing. Every element earns its place.

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?

This is a simple single-parameter tool with full schema coverage and essential behavioral disclosure (press+release semantics). Given the low complexity (1 param, no output schema needed), the description adequately covers what an agent needs to invoke it correctly. Could mention modifier support validation or intput targeting, but for a simple key-press tool, this is sufficient.

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% - the sole parameter 'key' is described as 'Key name or combo (e.g. 'Enter', 'Tab', 'Ctrl+S')'. The description reinforces this by listing examples like 'Enter', 'Ctrl+Shift+Z'. Since coverage is complete, the baseline of 3 is appropriate; the description adds validation context (supported formats) beyond the schema but largely overlaps with it.

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?

Description uses a clear verb ('Simulate') with a specific resource ('a key press and release'). It lists supported inputs including single keys and modifier combos with concrete examples ('Ctrl+S', 'Shift+A'). It's clearly distinguishable from sibling tools like imgui_type_text (text input) and imgui_click_widget (mouse clicking).

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 concrete usage examples (single keys and combos) which implicitly teach when to use the tool, but doesn't explicitly state when NOT to use it or name alternatives. However, with siblings like imgui_type_text and imgui_click_widget, the distinction is fairly self-evident from the tool purpose. Minor gap: no guidance on focusing widgets before key presses or distinguishing from text input for characters.

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