game_ui_click

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 mentions 'Fast and exact when it works' which hints at reliability but doesn't disclose side effects, whether it can be destructive, or what happens on hover/release. It does not clarify if it modifies game state or if it requires a connected game session. Minimal behavioral context beyond performance.

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 very concise: two short sentences. The primary purpose is front-loaded, and the usage tip about game_ui_dump is placed as a secondary note. Every sentence adds value with no redundant text.

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 description covers the core usage and mentions the prerequisite dump tool. However, it lacks details on error handling, interaction with game_connect, or specifics about how the action parameter affects behavior. Given the presence of an output schema, return format is not needed, but for a tool with multiple actions and a dependency, more context would help.

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%, so the description must clarify parameters. It lists the valid actions for the action parameter (click, press, release, hover, unhover), which adds meaning beyond the schema. However, it does not explain the widget parameter format (e.g., exact path, case sensitivity) or any constraints. Partial compensation.

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 clicks a UMG widget by name, with a specific verb and resource. It lists distinct actions (click, press, release, hover, unhover) which differentiates it from generic input tools like game_mouse or game_pad. However, it does not explicitly contrast with game_ui_focus, which might also interact with UI widgets, so it slightly lacks full sibling differentiation.

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 gives a clear prerequisite: use game_ui_dump first to learn widget names. This helps the agent know how to proceed. It does not state when to use this over alternatives like game_ui_focus or game_mouse, nor does it provide exclusions (e.g., if the widget is not clickable). The 'Fast and exact when it works' implies potential failure but does not describe fallback paths.

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